From legal text to a compliance schema

What a compliance schema actually is

A compliance obligation usually arrives as prose. It describes who must act, when they must act, what information they must provide, which exceptions apply, and what evidence should exist afterward. A team then has to translate that prose into something operational: a form, a spreadsheet, a ticket, an approval chain, or a collection of all four.

A compliance schema is a structured version of that operational interpretation. It defines:

• the facts a person must provide;
• the decisions the workflow must make;
• the conditions that reveal or require more information;
• the warnings or blocking failures that follow from those conditions; and
• the record retained when the workflow completes.

It is not the law itself. It is a versioned model of how a particular obligation should be handled in a particular context.

The useful boundary is simple: a schema can make an interpretation consistent and inspectable. It cannot remove judgment from a rule that genuinely requires judgment.

That boundary matters. A form that asks whether an incident creates a “risk to the rights and freedoms of natural persons” can collect the assessment and its reasons. It should not pretend that a dropdown has resolved every factual and legal question behind that assessment.

The six layers of a workable schema

Strong schemas separate concerns that are often mixed together in ordinary forms.

1. Source

Record the authority behind the workflow: legislation, regulation, regulator guidance, policy, contract, or internal control. Link to a stable primary source where possible and identify the relevant article or section.

A source reference gives reviewers somewhere to start. It does not prove that the interpretation is correct, which is why source and interpretation should remain distinct.

2. Scope

Before asking for incident dates or customer details, establish whether the workflow applies. Scope may depend on jurisdiction, entity type, sector, size, processing role, contract type, or the people affected.

Scope questions should be explicit. Hiding them in an administrator’s private instructions makes the final record difficult to explain.

3. Intake

Collect facts in the form in which they will be used. Dates should be dates. Counts should be numbers. Controlled categories should use deliberate options. Free text belongs where genuine description or reasoning is required.

The aim is not to eliminate prose. It is to avoid using prose for values that later need consistent validation, filtering, or reporting.

4. Decisions

Every branch should answer a recognisable question. For example:

• Is this incident significant?
• Is notification required?
• Is the ordinary deadline still open?
• Does an exception need review?
• Is a second communication required for affected people?

Name the decision and retain the facts that led to it. A result without its inputs is hard to audit.

5. Controls

Controls turn an intake into a workflow. They can require a missing field, reveal a follow-up question, reject an impossible value, or warn that a deadline may have passed.

Use blocking controls for structural failures: a required contact is missing, an end date precedes a start date, or a mandatory assessment has no result. Use notices for matters that need attention but should not be silently decided by software.

6. Evidence

The completed record should identify the schema and version used, the submitted values, the resulting decisions, completion time, and relevant delivery status. If a later version changes the questions or rules, the earlier record must remain tied to the earlier version.

This is the difference between “we have a form” and “we can show what process was followed.”

A repeatable design method

Start with the obligation, not the interface.

Step 1: write the obligation as a sentence

Use the pattern:

When trigger, the responsible party must perform action by deadline, containing required information, unless exception.

If the source contains several actions or deadlines, write several sentences. NIS2 incident reporting is a good example: the early warning, incident notification, and final report are separate stages rather than one oversized submission.

Step 2: mark every fact the sentence depends on

The trigger becomes input. The responsible party becomes scope or identity. The deadline requires a start time and a completion time. Required information becomes fields. Exceptions become decisions with supporting facts.

This pass reveals vague requirements early. If a rule depends on “high risk,” the workflow needs both an assessment and a place to explain it.

Step 3: classify each field

Use the narrowest useful type:

Avoid a single “Describe everything” field. It may be quick to build, but it prevents reliable completeness checks and creates work for every downstream reviewer.

Step 4: separate calculation from judgment

Software is good at calculating elapsed time, checking presence, comparing values, and applying clearly defined branches. It is less reliable when the law deliberately uses open concepts such as proportionality, likelihood, severity, or reasonable measures.

The schema can make those judgments visible. It can require the assessor, result, rationale, and review time. It should not hide a subjective conclusion behind an unexplained automatic flag.

Step 5: define the outcome

Decide what “complete” means. Completion may require every mandatory fact, an acknowledged warning, an approval, or evidence that an external filing was made. Define what is delivered to the next system and what remains in the audit record.

Step 6: test the uncomfortable cases

Test late submissions, unknown counts, conflicting dates, exceptions, phased information, and cases where the reporter cannot yet answer everything. Regulatory workflows often fail at the edges, not on the happy path.

Worked example GDPR Article 33

GDPR Article 33 requires a controller to notify the competent supervisory authority of a personal-data breach without undue delay and, where feasible, within 72 hours after awareness, unless the breach is unlikely to result in a risk to people’s rights and freedoms. A late notification must include reasons for the delay.

The same article identifies minimum notification content and permits information to be supplied in phases when it cannot be provided at the same time. It also requires the controller to document breaches so that compliance can be verified.

An operational interpretation might therefore include:

{
  "became_aware_at": "date-time",
  "risk_assessment": "unlikely | likely | high",
  "risk_rationale": "text",
  "breach_nature": "text",
  "people_affected_estimate": "number",
  "records_affected_estimate": "number",
  "likely_consequences": "text",
  "measures_taken": "text",
  "authority_notified_at": "date-time",
  "delay_reason": "text"
}

The workflow can calculate whether the recorded notification time is more than 72 hours after awareness. It can require a delay reason when appropriate. It can reveal the minimum notification fields when the risk assessment is not “unlikely.”

What it should not do is automatically conclude that notification was unnecessary merely because one person selected “unlikely.” A stronger design retains who made the assessment, why, and whether it received the organisation’s required review.

The supporting briefing on GDPR Article 33 breach notification follows that workflow in detail.

What not to automate

Automation should stop where the source requires contextual professional judgment.

Do not turn an illustrative threshold into a universal legal conclusion. Do not treat a regulator’s example as an exhaustive definition. Do not assume that an EU directive has identical procedures in every national implementation. Do not silently merge obligations that use similar words but have different triggers.

Some especially important boundaries are:

• Applicability: a schema can collect scope facts, but complex group structures or cross-border activities may need advice.
• Risk and significance: software can organise an assessment, not guarantee its legal conclusion.
• Authority and channel: the correct recipient and filing format can depend on national law and regulator systems.
• Current law: a published workflow needs an owner and a review cadence. Versioning preserves history; it does not keep an interpretation current by itself.

A publication checklist

Before releasing a compliance schema, check the following.

Authority

• Is the primary source linked?
• Are the relevant provisions identified?
• Is national implementation relevant?
• Does the schema state its jurisdiction and effective period?

Interpretation

• Can a reviewer distinguish source text from workflow choices?
• Are assumptions documented?
• Are subjective decisions assigned to a person?
• Are exceptions supported by facts rather than a bare checkbox?

Workflow

• Does every required field serve a defined decision or record?
• Do deadlines have a reliable starting event?
• Can incomplete or phased information be handled honestly?
• Are warnings distinguishable from blocking errors?

Evidence

• Is the released version immutable?
• Does the completed record retain the version used?
• Are decision inputs and outcomes kept together?
• Can another person understand what happened without reconstructing the form from memory?

Maintenance

• Is an owner responsible for updates?
• Is there a review date or change trigger?
• Can a superseded version stop new use without rewriting old records?
• Will users be told when a material workflow interpretation changes?

The result is not a machine that “does compliance.” It is something more useful: a controlled, reviewable way to perform one compliance task consistently and retain the evidence that it happened.