--- 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 - [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 CCPA | What Actually Changed in California Privacy](/artifacts/us/california-privacy-rights-act/ccpa-vs-cpra.md): A practical CPRA vs CCPA delta guide grounded in the current California statute, CPPA regulations, Proposition 24, and official agency guidance. - [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 Actually Changed in California Privacy](/artifacts/us/california-consumer-privacy-act/ccpa-vs-cpra.md): A practical CCPA vs CPRA delta guide grounded in the current California statute, CPPA regulations, and official agency guidance. - [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?ref=sorena.io) - 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?ref=sorena.io) - 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?ref=sorena.io) - 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?ref=sorena.io) - 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?ref=sorena.io) - 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?ref=sorena.io) - 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?ref=sorena.io) - 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?ref=sorena.io) - 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?ref=sorena.io) - 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?ref=sorena.io) - 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/doubl