Compliance that answers in everyday work

Nobody opens a policy document in the middle of their work. You decide on gut feeling, because looking it up takes longer than the decision itself, and the neatly written rule stays in the ISMS while exactly its case is passing by.

A rule that cannot be reached at the decisive moment exists on paper and is ineffective in practice. Where it would need to be reachable today is, to a large extent, the chat with a language model, and that is exactly where the same rule base can answer instead of sitting silent in a folder.

Why the folder does not answer

A rulebook in a folder fails in everyday work at three points, and none of them has to do with the content of the rules. The first is findability. Anyone with a concrete question would have to know which of the documents contains the answer, where in it, and in which of the often nested sections. When in doubt, this route is longer than the decision itself, so it is not taken.

The second point is currency. A document reflects the state of its last edit, not that of today. Legal situations change, deadlines shift, internal requirements are adjusted, and the copy in an employee’s head is usually even older than the document. An answer from memory is therefore doubly dangerous, because it presents an outdated state with the conviction of being current.

The third point is interpretation. Even someone who finds the right passage has to apply it to the specific case, and that is exactly where mistakes happen. A generally worded requirement never answers the specific question literally, but demands a translation step that hardly anyone does cleanly under time pressure. Living compliance addresses all three points by returning the matching rule findable, current and related to the concrete question.

Before, during and after the event

The real value of living compliance does not show in a folder, but at the moment of a question. The same, always current rule base can be tapped at three points in time: before something is built, while you are in the middle of the work, and after an incident has occurred.

Before a project, the rule base is an adviser. Anyone planning a new feature that processes user data wants to know early on what to consider, instead of fixing it afterwards. A question like “We want to evaluate email addresses for a new referral feature, what do we have to consider?” should get a concrete answer from your own data protection and security rules that points to purpose limitation, the required legal basis and the retention period. That way the rule becomes a design aid before effort flows in a direction that later has to be rolled back.

In the middle of the work, the rule base is a touchstone. A code review can be conducted not only against technical quality, but also against your own requirements, and this is where living compliance works most unobtrusively. When a pull request introduces a new data flow, the same review can ask whether the requirement for data minimisation is met, whether a new access right is too broad or whether a log accidentally writes personal data. The comparison happens where the decision is made, not weeks later in an audit, where omissions can only be documented but no longer prevented.

After an incident, the rule base is a compass. When something has happened, a possible data protection case or a security incident, speed counts, and the first question is often which reporting obligations and deadlines now apply. If a company falls under NIS2, the incident starts a tight reporting chain of an early warning within 24 hours, a more detailed notification within 72 hours and a final report within one month. A rule base that answers reliably at this moment which deadline is running and whom to report to shortens the time between “something has happened” and “we know what to do”, which makes the difference with such tight deadlines.

The hard deadlines and obligations of NIS2 itself are covered in depth in the article NIS2 takes effect. Here, only the mechanism behind it counts: the same rule base that advises before a project sets out the reporting route after an incident.

How the rules learn to answer

For a rule base to answer at the moment of a question, it has to be reachable where people work and ask, and today that is, to a large extent, the chat with a language model. The obvious but wrong route would be to simply hand the model all the policy documents and let it guess. That leads to plausible-sounding but non-binding answers, and in compliance an answer that is only roughly right is more dangerous than none at all, because it is delivered with the same conviction as a correct one.

The sustainable route is the same one we describe for cost data in the article Talking to your own numbers: do not tip the raw data into the model, but create controlled access via an MCP server. The language model phrases the question and the context, while the actual information comes from a maintained, versioned rule base. The model provides the language, the rule base provides the authority.

What matters is that the rule base remains a single, maintained source. Anyone running an ISMS according to ISO 27001 already has their requirements in structured form, and regulatory requirements such as those from NIS2 can be placed in the same base instead of being kept in a second document. Each rule gets not only a text, but also its origin and its version, so the information remains traceable later.

"retention-user-data": {
  "source": "ISMS policy A.8.10 / GDPR Art. 5",
  "statement": "Store personal data only as long as the purpose requires; delete or anonymise it afterwards.",
  "applies_to": ["production", "backup"],
  "version": "2026-09-01",
  "review_due": "2027-09-01"
}

So you can trust the answer

Information about a rule is only worth as much as you can trust it, and in compliance trust does not come from a fluent sentence, but from a verifiable origin. That is why every answer should carry the same provenance that we also attach to the cost answers: which rule it comes from, which version of that rule it is, and when it was last reviewed.

"provenance": {
  "rule": "retention-user-data",
  "source": "ISMS policy A.8.10 / GDPR Art. 5",
  "version": "2026-09-01",
  "last_reviewed": "2026-09-01",
  "notes": ["Rule review due in less than 12 months."]
}

The version is not a detail but the precondition, because a rule base that returns an outdated version is worse than one nobody trusts. That is exactly why every rule carries a review date, and the provenance warns when that date lies too far back. It is the same attitude with which we maintain this compendium itself, in which every article carries a review date and is regularly checked against reality. A rule that nobody reviews any more loses its value just like an article that stays stuck on an old state.

The art, then, is not to write more rules, but to make the existing ones available in such a way that they apply at the time of the question, name their origin and disclose their version. Only these three properties together, reachability, verifiability and currency, turn a rulebook into compliance that answers in everyday work.

What this means for you

Compliance does not protect by being documented, but by taking effect in the decision. The difference between a folder and a living rule base is not the number of rules, but their reachability at the moment of a question: before a project, in the middle of the work and after an incident. For a product company this means taking the existing requirements out of the folder and making them available through controlled access where the work happens, with their origin and version as a fixed part of every answer.

The first step is smaller than it looks, because the rules usually already exist and only need to be made connectable. Whether it is about bringing an existing ISMS to life or making the first rules queryable at all, we are happy to sort it out together with you.