A critical SaaS service goes down. The IT manager and the contract manager sit together in a shared drive, searching for the right contract. What was the agreed recovery time again? Are we entitled to service credits? Does this contract expire soon? Forty minutes later they have found the PDF, but the outage is still ongoing. This is the moment you realise you are not really managing your SLAs. You are only storing them.<\/p>\n\n\n\n
Monitoring IT supplier SLAs means something different from checking whether a service is technically running. It is about whether the contractual agreement is being met: the availability, the response time, the recovery time and the compensation when things fall short. Those agreements sit in PDFs, not in your system. And that is where the problem starts. According to research by WorldCC, PwC and McKinsey, 95 per cent of organisations lack full visibility into their own contractual obligations. With IT contracts and their stacks of annexes, that problem is at its worst.<\/p>\n\n\n\n
Your ERP or spend system does exactly what it was built for. It registers the supplier, the contract value and the invoices. It matches purchase orders and tracks the contract term. For the administrative basics, that is fine.<\/p>\n\n\n\n
But the ERP does not know the SLA standards. It does not know that you agreed 99.9 per cent availability with this hosting party. Nor does it know that the response time for a priority-1 incident is fifteen minutes. That detail sits in the contract annex. And no one reads that annex at the moment things go wrong.<\/p>\n\n\n\n
The difference is the one between registration and management. Your system registers that you have a contract. The content of that contract, the agreements and the outstanding obligations, lives somewhere else. Usually in Word, PDF and the heads of a few people. Registration stays in your system. You manage in a contract dashboard<\/a> on top of that system.<\/p>\n\n\n\n As an IT manager you probably have uptime monitoring running. A dashboard that pings whether a service is reachable and sends an alert during downtime. Useful, but it answers a technical question: is it still running?<\/p>\n\n\n\n That is different from the contractual question: is the agreement being met? A service can be technically available and still fall outside the agreed standard, for example because the response time for incidents is structurally exceeded. Measuring uptime tells you nothing about service credits, escalation procedures or recovery obligations.<\/p>\n\n\n\n There is another problem. The monthly performance report often comes from the supplier itself. That is a case of marking your own homework. Without your own source that places the agreed standard next to the measured performance, you have no independent counterweight. You believe what the supplier reports, or you work it out by hand.<\/p>\n\n\n\n To monitor your IT supplier SLAs at contract level, you record for each contract what was agreed and whether it is being met. The essentials:<\/p>\n\n\n\n Do not start with all five at once. First place availability and recovery time next to the actual performance, because those are the agreements that count during an outage. Service credits come next, because you can only settle them once you can prove the shortfall. Each point comes with the same question: who measures, and where is that agreement recorded? An SLA standard you cannot find when it matters is not a steering instrument. It is a file.<\/p>\n\n\n\n The Dutch Cybersecurity Act (Cbw), the Netherlands’ implementation of NIS2, came into force on 15 August 2026. Without a general transition period. Around 8,000 to 10,000 organisations are directly obliged to comply, with registration in the entity register via the NCSC.<\/p>\n\n\n\n For you as a contract owner it comes down to supply chain responsibility. The act requires you to demonstrably control cyber risks from your supplier chain. In practice: you need to know which ICT suppliers you have, which security and continuity requirements are in those contracts, and which agreements are outstanding. That is exactly the information now scattered across PDFs.<\/p>\n\n\n\n GRIP is not a cybersecurity tool and does not make anyone NIS2-compliant. GRIP gives you a firm grip on the contract side of that duty of care, so you can show which requirements are in which contract and what is outstanding. The rest of your security policy stands separate from that. You can read more about that contract side in this explanation of NIS2 and supplier contracts<\/a>.<\/p>\n\n\n\n In practice, a single party rarely delivers a complete service. Take a business-critical application: it runs at one supplier, the hosting goes through a second, and the management sits with a third. Each with its own SLA and its own definition of availability. Three contracts, three standards, three measurement methods.<\/p>\n\n\n\n During an outage, the responsibilities blur. The hosting party points to the application supplier, who in turn points to the management party. And meanwhile you are searching through three different contracts to find who is accountable for what. Without one overview that places those agreements side by side, you lose the discussion before it starts.<\/p>\n\n\n\n The solution does not start with a stricter SLA or an extra monitoring tool. You probably already have those. The solution starts with one source that brings together the agreed standard, the measured performance, the outstanding obligations and the contract term.<\/p>\n\n\n\nWhy technical monitoring is not SLA monitoring<\/h2>\n\n\n\n
Which SLA agreements to monitor at contract level with IT suppliers<\/h2>\n\n\n\n
\n
What does the Dutch Cybersecurity Act mean for your IT contracts?<\/h2>\n\n\n\n
The real problem: multiple suppliers, one service<\/h2>\n\n\n\n
SLA agreement and performance in one source<\/h2>\n\n\n\n