WorkflowEU DSA

DSA statement of reasons log workflow

Use this workflow to record each DSA moderation decision, generate the Article 17 statement of reasons, submit platform statements to the Commission's Transparency Database, and preserve the evidence needed for complaints and reporting.

Designed for online platform trust and safety, policy, legal, data, support, and compliance teams that need a usable log rather than a generic moderation checklist.

Author
Sorena AI
Published
May 9, 2026
Updated
May 9, 2026
Sections
5

Structured answer sets in this page tree.

Primary sources
4

Cited legal and guidance references.

Publication metadata
Sorena AI
Published May 9, 2026
Updated May 9, 2026
Overview

The DSA statement of reasons log should connect a content moderation action to the user notice, the database submission, and any later complaint or dispute. The log is useful only if it captures the decision category, the Article 17 reasons, redress information, submission status, and quality checks before the decision is closed.

Section 1

When to open a statement of reasons log entry

Open a log entry whenever a hosting service imposes a DSA Article 17 restriction because user-provided information is considered illegal content or incompatible with the service's terms. The covered restrictions include content visibility restrictions, removal or disabling of access, demotion, restriction or termination of monetisation, suspension or termination of the service, and suspension or termination of the account.

For online platforms, the same log entry should also drive the Transparency Database submission required by Article 24(5). Keep the recipient-facing statement and the public database payload aligned, but remove personal data from the database submission.

  • Trigger source: notice under Article 16, trusted flagger notice, authority order routing, automated detection, human review, or own-initiative moderation.
  • Decision basis: illegal content, terms-and-conditions incompatibility, or both; record the exact legal ground or contractual rule relied on.
  • Restriction type: visibility, access, demotion, monetisation, service access, account status, or another Article 17 measure.
  • Exclusion check: mark deceptive high-volume commercial content separately because Article 17 states that the statement-of-reasons duty does not apply to that category.
  • Contact-detail check: Article 17 applies where the relevant electronic contact details are known to the provider.
Section 2

Fields the log should capture before the notice is sent

The log should be structured enough to produce a clear user notice without rework. Use controlled fields for reporting and searchable free-text fields for the facts, circumstances, and explanation that make the decision understandable.

Do not close the entry until the reviewer can explain what happened, why the rule applies, whether automation was used, what territory and duration apply, and how the recipient can challenge the decision.

  • Decision identifiers: platform service, moderation case ID, content or account reference, recipient contact status, decision timestamp, reviewer or system source, and appeal case link if one later exists.
  • Action details: action taken, territorial scope, duration, content URL or object identifier where available, account or service restriction scope, and monetisation impact where relevant.
  • Article 17 reasons: facts and circumstances relied on, notice source where relevant, automated-means flag, legal ground for alleged illegal content, terms ground for rule incompatibility, and plain-language explanation.
  • User redress fields: internal complaint link or instructions where Article 20 applies, out-of-court dispute settlement information where applicable, judicial redress text, and the date the recipient was informed.
  • Database fields: personal-data removal status, Transparency Database submission method, submission environment, API or webform status, submission ID, error response, retry owner, and production confirmation.
Section 3

Transparency Database submission workflow

For an online platform, the statement-of-reasons log should create a submission queue. Each queued item needs a validation result, personal-data check, submission method, and reconciliation status so the public database record does not drift from the user-facing decision.

The Commission FAQ describes an onboarding path through the Digital Services Coordinator, sandbox testing, and then production submission through API or webform. High-volume operations should route eligible records to the batch API endpoint rather than relying on manual webform entry.

  • Validate: confirm the moderation action is an Article 17 decision and that the payload contains the required statement fields.
  • Minimise: strip personal data from the database payload and keep redress options out of the public submission because the Commission FAQ says redress options are relevant only for the addressee.
  • Submit: send through the API or webform after onboarding; record whether the platform used single-record API, batch API, or webform submission.
  • Reconcile: store the submission ID or confirmation, error code, retry count, final status, and the date the record became available in public search or daily dumps where verified.
  • Monitor: compare submitted counts against internal moderation counts and investigate gaps, duplicates, rejected payloads, and records containing personal data.
Section 5

Retention and QA controls for the statement log

Do not rely on the public Transparency Database as the platform's only record. The Commission FAQ says statements are searchable for six months, daily dump files are retained for 18 months, and dashboard aggregate statistics cover the last five years; internal evidence may need to support complaints, regulator questions, and transparency reporting after public search availability changes.

Run QA before notice delivery and again after database submission. The QA owner should check both legal completeness and data quality: a statement can satisfy the field list and still be too vague for a recipient to understand or challenge.

  • Completeness QA: every Article 17 minimum field is populated or marked not applicable with a reason; redress text is present where required.
  • Specificity QA: facts, circumstances, legal grounds, and contractual grounds are precise enough for the recipient to understand the decision.
  • Automation QA: automated detection and automated decision support are flagged consistently between the user notice, database payload, and internal moderation record.
  • Privacy QA: database payloads exclude personal data and redress information that should be sent only to the addressee.
  • Retention QA: preserve internal statement records, submission confirmations, complaint links, dispute links, corrections, and report mapping separately from the public database retention window.
  • Correction QA: if a transparency report is updated to correct inaccuracies, errors, or methodology changes, mark the updated version and reason for the change as required by the implementing regulation.
Recommended next step

Turn Article 17 reasons into a maintained log

Sorena can help structure DSA statement records, database submission checks, complaint links, and reporting fields so trust and safety teams can explain and audit moderation decisions.

Primary sources

References and citations

digital-strategy.ec.europa.eu
Referenced sections
  • The FAQ grounds the public database retention windows and the distinction between full search, daily dumps, and dashboard aggregates.
"Search data will be retained for six months"
Related guides

Explore more topics

DSA Ads and Recommender Systems: transparency duties, user choice, and evidence
A grounded DSA guide to ad labels, targeting restrictions, recommender parameter disclosure, non-profiling options for VLOPs and VLOSEs, ad repositories, and compliance evidence.
DSA Applicability Test: classify intermediary services, platforms, marketplaces, VLOPs and VLOSEs
A source-grounded EU Digital Services Act applicability test for classifying intermediary services, hosting services, online platforms, marketplaces, VLOPs and VLOSEs.
DSA Article 28 minors protection guide for online platforms
EU Digital Services Act guide to Article 28 minors protection: platform scope, child-safety measures, targeted ads limits, recommender controls, and grounded evidence.
DSA average monthly active recipients: what platforms must publish
A grounded FAQ on average monthly active recipients under the EU Digital Services Act, including publication, EU recipient scope, the 45 million VLOP/VLOSE threshold, and evidence records.
DSA Complaint and Dispute Workflows for Online Platforms
Build DSA complaint, appeal, statement-of-reasons, and out-of-court dispute workflows for online platform moderation decisions.
DSA crisis response for VLOPs and VLOSEs
EU Digital Services Act crisis response guide for VLOPs and VLOSEs: Article 36 Commission decisions, Article 48 crisis protocols, mitigation, governance, requests for information, and records.
DSA Dark Patterns: interface design checks for online platforms
Article 25 DSA guidance for reviewing online platform interfaces for deceptive, manipulative, or choice-distorting design patterns.
DSA Enforcement and Penalties in the EU
How Digital Services Act enforcement works: Commission and Digital Services Coordinator roles, VLOP and VLOSE investigations, fines, periodic penalty payments, and evidence readiness.
DSA illegal content notices: what must be included?
A grounded FAQ on EU Digital Services Act illegal-content notices: Article 16 notice elements, acknowledgement, decision notices, trusted flagger priority, statements of reasons, and records.
DSA Marketplace Trader Traceability FAQ
Answer to what EU Digital Services Act Article 30 requires online marketplaces to collect, verify, display, retain, and evidence for trader traceability.
DSA Marketplace Trader Traceability Guide
EU Digital Services Act guide for online marketplaces collecting, checking, displaying, storing, and evidencing trader traceability information.
DSA notice and action plus statements of reasons guide
A grounded Digital Services Act guide for notice intake, moderation decisions, statements of reasons, DSA Transparency Database submission, complaints, appeals, trusted flaggers, and records.
DSA Notice and Action Workflow for Hosting Services and Online Platforms
A grounded DSA notice-and-action workflow covering notice intake, completeness checks, trusted flaggers, decisions, user communications, statements of reasons, appeals, and records.
DSA recommender transparency FAQ: Article 27 and VLOP options
What EU Digital Services Act recommender transparency requires: main parameters, user options, VLOP/VLOSE non-profiling choices, and evidence to keep.
DSA researcher data access for VLOPs and VLOSEs
Article 40 DSA guide to vetted researcher data access for VLOPs and VLOSEs: DSC requests, eligibility checks, amendment grounds, confidentiality, security, and evidence records.
DSA service tier classifier for platforms, marketplaces, VLOPs and VLOSEs
Classify a digital service under the EU Digital Services Act as intermediary, hosting, online platform, marketplace, VLOP or VLOSE, with EU recipient-count evidence and obligation outputs.
DSA statement of reasons FAQ
When DSA statements of reasons are required, what they must contain, when online platforms submit them to the DSA Transparency Database, and what appeal records to keep.
DSA transparency report template fields and cadence
A source-grounded template outline for Digital Services Act transparency reports, covering applicable service tiers, reporting periods, CSV/XLSX format, retention, statement-of-reasons links, and required evidence tables.
DSA Transparency Reporting Obligations by Provider Tier
A grounded guide to EU Digital Services Act transparency reports, active-recipient publication, statements-of-reasons submissions, VLOP/VLOSE reports, templates, cadence, and evidence.
DSA VLOP and VLOSE Risk Assessments and Mitigation Guide
Grounded guide to Digital Services Act systemic risk assessments, mitigation measures, audits, transparency reports, data access, and governance evidence for VLOPs and VLOSEs.
DSA VLOP Audit Pack Workflow: Risk, Mitigation, Audit, and Transparency Records
Build a DSA VLOP or VLOSE audit pack covering Article 34 risk assessments, Article 35 mitigations, independent-audit evidence, transparency reports, data access, and compliance governance.
DSA VLOP Risk Assessment FAQ: Article 34, Mitigation, Audits
What VLOPs and VLOSEs must assess under the EU Digital Services Act, when to reassess, how Article 35 mitigation and annual audit evidence fit together, and what records to keep.
DSA vs DMA Platform Rules
Compare the EU Digital Services Act and Digital Markets Act by scope, designation thresholds, obligations, enforcement, evidence, and practical team ownership.
DSA vs GDPR: online-platform governance and personal-data obligations
Compare the EU Digital Services Act and EU GDPR by scope, ads, recommenders, minors, transparency, complaints, enforcement, and evidence.
DSA vs P2B Regulation: EU platform obligations compared
Compare the EU Digital Services Act with the Platform-to-Business Regulation for platform scope, business-user terms, content moderation, ranking transparency, complaints, enforcement, and evidence.
DSA vs Terrorist Content Online Regulation: notice-and-action vs removal orders
Compare DSA content-governance duties with the EU Terrorist Content Online Regulation removal-order workflow for scope, timing, evidence, authorities, and team ownership.
EU Digital Services Act checklist for platforms and hosting services
A grounded DSA checklist for classifying service tiers, notice-and-action, statements of reasons, complaints, transparency reports, ads, recommenders, trader traceability, VLOP/VLOSE duties, and evidence records.
EU Digital Services Act Compliance Guide
DSA compliance guide for intermediary services, hosting providers, online platforms, marketplaces, and VLOP/VLOSE teams: obligations, controls, and evidence to keep.
EU Digital Services Act FAQ: DSA scope, platform duties, VLOPs, reports, and penalties
Concise EU Digital Services Act FAQ covering intermediary-service scope, active-recipient thresholds, illegal-content notices, statements of reasons, trader traceability, recommender transparency, systemic-risk duties, reporting, penalties, and complaints.
EU Digital Services Act penalties and fines: caps and enforcement roles
DSA penalty caps and enforcement roles: Member State fines, Commission fines for VLOPs and VLOSEs, 1% procedural fines, and 5% periodic penalty payments.
EU Digital Services Act requirements by service tier
Overview of DSA obligations for intermediary services, hosting providers, online platforms, marketplaces, VLOPs and VLOSEs, including notices, complaints, ads, transparency reports, audits, data access and enforcement.
EU Digital Services Act service types and scope
Classify DSA service scope across mere conduit, caching, hosting, online platforms, marketplaces, online search engines, and VLOP/VLOSE threshold duties.
EU DSA deadlines and compliance calendar: application dates, reporting cycles, and VLOP clocks
Calendar view of grounded EU Digital Services Act dates: full application, user-number publication, VLOP/VLOSE designation clocks, statements of reasons, and transparency reporting cycles.
EU DSA Transparency Calendar: reporting, SoR database, AMAR updates
Build a DSA transparency calendar for annual reports, statement-of-reasons database submissions, active-recipient updates, and VLOP/VLOSE audit touchpoints.
EU DSA vs UK Online Safety Act: scope, duties, regulator, and evidence
Compare the EU Digital Services Act and UK Online Safety Act for platform scope, risk assessments, child protection, transparency, regulators, enforcement, and owners.