It is Friday afternoon and a storage failure has hit several systems. Besides restoring service, a second clock is now running: if this is a major incident, it has to be reported within a short deadline. Someone asks: “Which services were hit, how many users, and how critical are they?” The answer is pieced together from monitoring, a spreadsheet of services and the memory of experienced colleagues. The same questions come again during an inspection – only later, and with a request for evidence.
What the regulations ask
NIS2 and DORA differ in scope and in their supervisory authorities, but from an IT operations point of view the same requirements keep coming back:
- know the impact of an outage on services and their criticality,
- report major incidents within set deadlines and with sufficient evidence,
- manage changes and vulnerabilities and be able to show who approved what,
- keep an overview of ICT services and providers that operations depend on,
- trace accountability – who owns the service and who changed what, when.
None of these requirements is new. What is new is the pressure for the answers to be quick, complete and provable.
What Stilla covers today
The foundation of regulatory answers is the data Stilla keeps for everyday operations:
- A dependency map from business service to infrastructure and impact calculation that takes redundancy into account – clusters, database replication, mirrored storage.
- An owner for every service, scoped roles and a RACI matrix that Stilla checks against permissions.
- An immutable audit trail for five years; for configuration, the state before and after a change is stored.
- Managed changes approved by the owner of the affected service, maintenance windows and change freezes.
- Service contracts and vendor SLAs, including incident escalation to the vendor according to the contract.
- Vulnerabilities by service with deadlines by severity, distinguishing actively exploited flaws.
When an incident happens, Stilla shows the affected services from the dependency map, not from an estimate. The service owner can be traced, and the change history shows what has changed in recent days.
What is in preparation
On top of this data we are building regulatory outputs that are not yet part of the product:
- major incident classification against NIS2 and DORA criteria, derived from the impact in the CMDB,
- a pre-filled report with timeline and impact,
- a register of ICT services and providers under DORA.
The principle will stay the same as in the rest of the product: Stilla prepares the evidence, a person always decides and submits. We will confirm the release timing with pilot customers.
Where to start
A regulatory answer is only as good as the data beneath it. That is why we recommend starting where it pays off even without regulation: with the key services, their owners and the dependency map. Whoever has this in order has most of the work done – and on a Friday afternoon answers from data, not from memory.
Stilla does not replace legal assessment. Review your organisation’s specific obligations with your compliance team.
Stilla Standard
For organisations that want a reliable CMDB and managed ITSM processes.