Legal assessment and information security management determine which requirements apply to your organisation. IT provides reliable information on systems, dependencies and safeguards. A new backup system or a second data centre alone does not demonstrate NIS2 compliance.
Requirements
Clarify scope, risks and responsibilities
Implementation
Apply measures to the actual infrastructure
Evidence
Document configuration, tests and outstanding issues
What you should have at the end
| Workstream | Working basis | What makes it useful |
|---|---|---|
| Systems and dependencies | Overview of critical applications and core services | Each application has an identified owner and documented dependencies. |
| Administrative access | Documented permissions and emergency access | Access is defined and tested for failure of normal authentication services. |
| Updates and support | Inventory with versions and end-of-support dates | Outstanding actions have owners and deadlines. |
| Recovery | Records of practical tests | Duration, data state and business functionality are traceable. |
| Operations | Change and incident records | Decisions and their implementation can be traced. |
Start with one critical application
Take an inventory-management application: where does it run, which database does it need, how do users sign in and who operates the interfaces? Map this estate to the requirements set by your information security team. The following working materials are neither a complete NIS2 checklist nor proof of compliance.
Build a usable system inventory
The inventory should show which business processes depend on which systems, who owns them and where safeguards exist. Include external operators and systems approaching end of support. More important than a large document is an inventory your team can reliably keep current.
- Record identities, permissions, network segments and administrative access.
- Keep patch levels, support status and ownership traceable for each system.
- Document backup paths, recovery objectives and external dependencies.
Gather evidence from operations
A useful test record links the system ID, responsible person, test date, failure scenario and result. For example: “Inventory application restored in an isolated environment; test order saved and reopened; email integration not tested.” Link the test report and assign an owner and date for the remaining check. This is more useful than “backup exists”, but is not standalone proof of compliance.
Questions to resolve
- Are scope and responsibilities clear?
- Can critical processes be mapped to their technical dependencies?
- Do tests demonstrate the defined objectives, with outstanding actions assigned?