Compliance Is a Chain of Questions. Most Teams Answer Them in Six Different Places.
Six questions, six places
When I talk to Trust & Safety and compliance teams, the conversation always reaches the same questions, in the same order.
What exists? What applies to us? What does it mean? How do we implement it? How do we know we're compliant? How do we prove it?
None of these is new, and most teams can answer every one of them. The problem is who answers them. In most organisations, each question belongs to a different person, using a different tool, at a different time. Monitoring is a newsletter someone reads. Applicability is a memo from outside counsel. Interpretation is a workshop with legal. Implementation is a set of Jira tickets. Verification, if it happens, is Product. Proof is a folder of screenshots someone assembles the week before the audit.
Each answer is the input to the next question. Compliance is a chain, and in most organisations every link sits in a different place. Every time an answer passes from one person to the next, something gets lost.
The clearest way to see this is to follow one obligation all the way through.
Following one article: DSA Article 27
Article 27 is about recommender systems: the logic that decides what appears in your feed, and in what order. It's a short article. It's also a good test of everything that can go wrong between a regulation and a product.
1. What exists?
Before anyone asks whether Article 27 applies, someone has to know it's there, and know whether anything around it has moved: new guidance, an enforcement decision that shows how the Commission reads it, a related obligation that changes the picture. Close to 40 online safety laws now exist worldwide, and none of them stands still. For most lean teams, this question is answered by whoever happened to read the right newsletter that week.
2. What applies to us?
Article 27 applies to every online platform that uses a recommender system, from a mid-sized marketplace to a VLOP. As we wrote in our post on categorisation, that's one feature flag: ship a "For you" feed and you've switched on a new set of obligations. The one carve-out is size: micro and small enterprises are exempt from the section Article 27 sits in, and they lose that exemption the moment they're designated a VLOP. The answer depends on facts about your product and your company, and both change.
3. What does it mean?
The article asks for three things. Set out the main parameters of your recommender system in your terms and conditions, "in plain and intelligible language." Explain the most significant criteria and why they matter as much as they do. And, where several options are available, give users a functionality to select and modify their preferred option at any time, directly and easily accessible from the section of the interface where the content is being prioritised.
That last clause is where interpretation earns its keep. "Where several options are available" means the duty to offer a control depends on whether you offer options at all. "Directly and easily accessible from the section where the content is prioritised" means the control belongs on or next to the feed, not three menus deep in account settings.
4. How do we implement it?
Now the article becomes work for two teams. The legal team writes a section of the terms explaining the main parameters and their relative weight. The product team builds the control: a toggle or menu, reachable from the feed itself, that lets a user switch between ranking options whenever they want. That's two deliverables from one article, owned by two teams.
5. How do we know we're compliant?
This is where most programmes stop looking. Usually the terms get reviewed and the ticket gets closed. But the DSA regulates how the platform behaves, so the only real check is to act like a user. Open the feed, look for the control, change the option, and confirm the feed changes. Then do it again next month, because the feed was redesigned in between.
6. How do we prove it?
A regulator or auditor wants to see what was checked, when, against which provision, and what the platform actually did. A policy PDF shows intent. Timestamped evidence of the control working, linked back to Article 27(3), shows compliance.
Where it breaks
Picture this:
The terms of service promise users they can switch to a chronological feed. That section was written and published by the legal team. Six months later, a feed redesign moves the toggle from the feed into a settings sub-page. Nobody did anything wrong: the designer didn't know the toggle's placement was a legal requirement, and the legal team never saw the redesign.
On paper, the platform is compliant. The terms say the right things, and the original ticket was closed. In the product, it isn't, and nothing in the process will notice until someone outside the company does.
That isn't a failure of any single question. Every question was answered correctly at some point. The failure is that the answers weren't connected: question 4's output, "the toggle lives on the feed," never reached anyone responsible for question 5.
The case for one system
This is the argument I keep coming back to. You don't fix compliance by getting better at any one of these questions. You fix it by keeping the chain intact: the obligation is derived from the article, the test from the obligation, the evidence from the test, and the report from the evidence. Then, when something changes at either end, a new feature or a new guideline, the change travels along the chain instead of stopping at a handoff.
That's what we've built Codeliance to do for questions two through six. Applicability is a live input, not a form. Each obligation is written in plain language and linked back to its article. Each obligation carries a recommendation for how to implement it. Scenarios test how the platform actually behaves. Evidence is captured as the test runs, not reconstructed later.
The first question is where we're heading next. Monitoring the landscape is the step that starts every chain, and right now it's the one most teams leave to chance. I'll share more when it's ready.
Back to 2017
When I led GDPR readiness for Search Trust & Safety, I wished for a magic button. I didn't really want magic. I wanted a way for each answer to reach the next question without getting lost on the way.
If you'd like to see how your platform's chain holds up, the DSA Quick Check is a good place to start. And I'd love to hear which of the six questions takes your team the most time.