← Back to news 30.07.2026

It is in the contract. Nobody ever checked.

Response time, certificate, incident notification duty, deletion at contract end: security requirements get negotiated once and then never touched again. Why every requirement needs a direction and a form of evidence, and why provided is not a permanent state.

The most diligent moment of a supplier relationship comes before it begins. In negotiation people fight over response times, certificates, incident notification duties. Then it gets signed and the contract moves to the archive. Three years later an assessment asks how you ensure suppliers meet the requirements you set yourself. The honest answer is often: you do not. They were agreed, not monitored.

Requirements have a direction

People almost always think of what the supplier owes. Yet roughly half of contractual security requirements run the other way: revoke access promptly, name contacts, announce system changes. Whoever does not track that side comes off worse than expected in the first escalation, because the supplier can evidence its duties to cooperate and you cannot.

Without a form of evidence, a requirement is only a sentence

"The supplier is certified to ISO 27001" sounds like a control point but remains a sentence until you define what the evidence is and when it will be requested again. Certificate, audit report, penetration test report and self-declaration carry very different weight. That belongs in the moment of signing, because nobody adds it later.

And provided is not a permanent state. A certificate that existed in 2024 does not exist in 2026. The interesting status change is the one from provided to expired, and it happens silently. The same holds for SLA numbers: four hours response time says little unless it is stated when the clock starts and what happens when it is missed.

NIS2 requires supply chain security as ongoing management, not a one-off selection decision, and ISO 27001 requires monitoring of agreed services in its supplier controls. Both fail at the same point: the contract is a document, but the commitments inside it are nowhere control points with a date and an owner.

How isidaten runs contracts

In contract management a contract carries more than a term and a file. Requirements are maintained individually, with direction, criticality, category, form of evidence, evidence status, due date, recurrence, owner and clause reference. Alongside sit obligations with deadlines and SLA definitions with target value, service hours and escalation rules.

Checking happens daily: three background runs flag what is overdue, warn ahead of upcoming deadlines and automatically move recurring evidence from provided to expired once due. The contract is linked to the objects it concerns, from IT systems and software through processes and rooms to the record of processing activities. So when it expires, what hangs off it is visible, not just that it expires.

More on the contract management module page and the NIS2 solution page. Why the data processing agreement and the record of processing activities drift apart was covered here recently.

Matching solution isidaten for NIS2

Questions about this update?

Talk to us – we are happy to show you this feature in a demo.