DSA statement of reasons log workflow

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, suspension, termination, or other restriction of monetary payments, suspension or termination of the service, and suspension or termination of the account.

For online platforms covered by Article 24 paragraph 5 (Article 24(5)), the same log entry should also drive the Transparency Database submission. Article 19 can exclude qualifying micro and small online-platform providers from that Section 3 duty, while leaving the Article 17 hosting duty intact. Keep the recipient-facing statement and the public database payload aligned, but remove personal data from the database submission.

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.

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.

The statement log should not stop at the original moderation action. It should preserve the user's challenge path because Article 17 requires clear and user-friendly redress information, and Article 20 gives recipients access to an electronic, free internal complaint-handling system for at least six months after they are informed of covered platform decisions.

When a complaint or dispute is opened, link it back to the original statement-of-reasons entry. That link is needed to report complaint outcomes, reversals, median handling time, out-of-court disputes, and implementation of dispute outcomes in transparency reports.

Do not rely on the public Transparency Database as the platform's only record. The Commission FAQ currently says statements are searchable for 180 days, daily dump files remain available for 540 days before archival, and dashboard aggregate statistics cover the last five years. The FAQ also says this retention policy may change. Internal retention should follow the provider's applicable legal, regulatory, dispute, and evidence requirements rather than treating the public database windows as a statutory retention schedule.

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.