Function matrix: GRC tools vs NetDefiner

Focus: NIS2. The table highlights what is typically automated versus what requires manual work.

Function (NIS2 focus)	Traditional GRC tools	NetDefiner	Purpose in NIS2
Inventory of systems, services, and assets	Register/CMDB and manual updates (M)	Inventory directly from the environment (A)	Basis for risk actions and traceability
Classification of systems and information	Classification via forms and register fields (M)	Classification based on inventory (A) + confirmations (M)	Prioritization of protection measures
Define scope and what is included	Scope defined in registers (M)	Scope derived from inventory (A) and confirmed via approvals (M)	Clear boundary for ownership and follow-up
Assign responsibility (system owners, decision-makers)	Responsibility linked in registers (M)	Responsibility linked to inventoried objects (A) and confirmed via approvals (M)	Governance and accountability
Risk assessment per system/service	Risk items are created and maintained (M)	Risk assessment based on current state (A) + confirmations (M)	Risk-driven security measures
Gap assessment against NIS2	Checklists/assessments (M)	Gap based on current state (A) + confirmations (M) + evidence (A)	Traceable current state against requirements
Action plan (risk treatment)	Actions created in workflow (M)	Action plan based on identified gaps/risks (A) and confirmed by owners (M)	Prioritized actions that can be followed up
Issue and action management	Tasks/issues with status and ownership (M)	Actions linked to evidence (A) and approvals (M)	Execution and follow-up
Verification of completed actions	Closure via documentation/sampling (M)	Verification with evidence from the environment (A) and approval at closure (M)	Traceable closure of deviations
Digital approvals (sign-off)	Approval flows (M)	Approval linked to current state/actions/closure with evidence (A) and decisions (M)	Who approved what, when, and why
Evidence management	Evidence collected and uploaded (M)	Evidence built continuously from inventory and flows (A)	Audit-ready evidence without the after-the-fact scramble
Chain: risk -> action -> verification -> approval	Mapping in registers (M)	Traceable chain built from current state/actions/verification (A) and decisions (M)	Coherent evidence for supervision/audit
Continuous change detection	External integrations or manual follow-up (M)	Change detection per client in production (A)	Ongoing control between audit cycles
Change -> new follow-up	Reassessment and updates (M)	Changes create follow-up points in the flow (A)	Compliance updated when reality changes
Incident handling (process and flow)	Incident module or ITSM integration (M)	Incident flow with roles, timeline, evidence (A), and decisions/actions (M)	Incident process as part of the governance chain
Incident reporting and documentation	Evidence gathered and compiled (M)	Timeline and evidence built continuously (A) and completed/attested (M)	Evidence for correct and fast reporting
Post-incident follow-up (lessons learned)	Follow-up issues created (M)	Lessons linked to risk/gap and action plan (A) with approvals (M)	Improvement cycle after incident
Training as an action and proof	Task in workflow or separate LMS (M)	Training planned/followed up in the same chain as risk/action (A) and confirmed (M)	Competence uplift as part of risk measures
Supplier and third-party risk	Questionnaires/assessments (M)	Supplier requirements and follow-up linked to affected systems/services (A) with confirmations (M)	Risk management for dependencies
Role-based views and reports	Dashboards based on manually updated data (M)	Dashboards based on continuous evidence from the environment (A) and decisions (M)	Management/IT/CISO/audit see the same status view
Export of evidence for audit/supervision	Compilation of audit package (M)	Collected evidence from current state/actions/verification (A) and approvals (M)	Fast audit-ready evidence package

Note: (A) = Automated (driven/updated by the system). (M) = Manual (requires confirmation, decisions, or human input).