How should organisations implement ICT risk management in existing system landscapes without creating another silo?

Treat ICT risk management as an integrated control process, not a standalone register. Start by mapping relevant assets, data sources, and ownership into the current environment, then connect risk assessment to operational workflows. The goal is transparent and controllable risk management that can be maintained as systems change, rather than a one-time assessment that quickly goes stale.

Why This Matters for Security Teams

ICT risk management fails when it is treated as a separate compliance exercise instead of part of how systems are built, operated, and changed. In existing landscapes, the real risk is fragmentation: asset inventories live in one tool, ownership in another, control evidence in a third, and operational decisions happen elsewhere. That creates blind spots, duplicate work, and stale risk decisions that do not match current reality.

Practitioners usually get this wrong by starting with a register before they have integrated sources of truth. The better pattern is to embed risk data into the operational systems already used for service management, change control, identity, and monitoring. That keeps ownership explicit, makes reviews repeatable, and turns risk management into a living control process rather than a periodic document review. NIST’s Cybersecurity Framework 2.0 supports this kind of continuous, outcome-based approach, while NHIMG’s Ultimate Guide to NHIs — Regulatory and Audit Perspectives shows how auditability depends on live governance, not spreadsheet control. In practice, many security teams encounter risk misalignment only after a change or incident has already exposed the gap, rather than through intentional design.

How It Works in Practice

The most effective way to avoid a new silo is to make ICT risk a property of the systems landscape, not a separate program. Start by linking each critical asset, service, and non-human identity to an owner, a business purpose, and an operational control path. Then connect risk assessment to existing workflows such as change approval, access reviews, incident management, and vendor oversight. This creates a closed loop: when the environment changes, the risk record changes with it.

Operationally, that means three things. First, use the current asset inventory as the baseline and enrich it with data from configuration management, identity platforms, cloud logs, and secrets management. Second, define control triggers that are evaluated inside normal processes, such as new service onboarding, certificate rotation, privileged access requests, and third-party connections. Third, assign evidence collection to the system that performs the control, rather than asking teams to re-enter the same facts elsewhere.

For organisations managing large estates of NHIs, this is especially important because exposures often sit outside human-led governance. NHIMG notes in the Ultimate Guide to NHIs that 68% of organisations do not know how to fully address NHI risks, which is a strong signal that visibility and process integration remain weak. A practical implementation also aligns with NIST SP 800-53 Rev. 5 Security and Privacy Controls, especially where control inheritance and continuous monitoring are used to reduce duplication.

• Use one operational inventory for assets, identities, and control ownership.
• Embed risk scoring into change, access, and incident workflows.
• Automate evidence capture where controls are executed.
• Refresh risk status from authoritative system data, not manual attestations alone.

These controls tend to break down when legacy platforms cannot expose reliable ownership, identity, or configuration data because the risk process then depends on manual reconciliation.

Common Variations and Edge Cases

Tighter integration often increases implementation effort, requiring organisations to balance control quality against legacy constraints, data quality, and team capacity. That is especially true in mixed environments where on-premises platforms, cloud services, and outsourced operations all manage different parts of the same risk surface.

There is no universal standard for this yet, so current guidance suggests choosing the operating model that fits the maturity of the landscape. In highly regulated environments, such as firms aligning to DORA, the emphasis is often on provable governance, rapid escalation, and traceable remediation. In faster-moving environments, the priority may be simpler: keep a small set of authoritative risk attributes current and attach them to the workflows teams already use.

Edge cases usually appear where ownership is shared, assets are ephemeral, or tooling is inconsistent across business units. In those cases, the best practice is evolving toward minimum viable integration: a single risk taxonomy, clear service ownership, and automated sync from authoritative sources. NHIMG’s NHI Lifecycle Management Guide is useful here because lifecycle control is often the missing bridge between discovery, remediation, and audit readiness. The goal is not perfect centralisation, but enough integration that the risk picture stays current as systems change.

Related resources from NHI Mgmt Group

• How should organisations build ICT risk management that satisfies DORA, NIS2, and ISO 27001 without creating extra operational drag?
• How should organisations onboard contractors with time-bound access without creating standing privilege risk?
• How should organisations use GenAI with identity data without creating unnecessary privacy risk?
• How should organisations prepare for stricter D365 F&SC license validation without creating audit risk?