Risk control is any measure used to reduce, contain, transfer, or monitor ICT risk. Controls can be technical, procedural, or governance-based, and they are most effective when they are traceable to a specific risk, measured against clear ownership, and reviewed as the environment changes.
Expanded Definition
Risk control is the practical expression of risk treatment in ICT and NHI governance: a measure that reduces likelihood, reduces impact, transfers exposure, or monitors conditions that can change the risk profile over time. In NHI security, this includes technical controls such as secret rotation and vaulting, procedural controls such as approval workflows, and governance controls such as ownership, exception handling, and review cadence. The concept aligns closely with the control logic described in the NIST Cybersecurity Framework 2.0, but usage in the industry is still broad and sometimes inconsistent across risk, compliance, and security teams.
The distinction that matters is traceability: a control is not just a safeguard, it should be tied to a specific risk statement, assigned to a named owner, and tested against a measurable outcome. In NHI environments, that means controls must account for machine-to-machine trust, service account sprawl, and secrets lifecycle failures rather than only human access patterns. NHI control planning is often discussed in the Top 10 NHI Issues and the Ultimate Guide to NHIs. The most common misapplication is treating a policy statement as a risk control, which occurs when no owner, metric, or review trigger exists.
Examples and Use Cases
Implementing risk controls rigorously often introduces operational friction, requiring organisations to weigh stronger assurance against deployment speed and administrative overhead.
- Rotating API keys on a fixed schedule to reduce the window of exposure, while coordinating with application owners to avoid outages.
- Requiring approval and justification before granting a service account elevated privileges, then reviewing the grant against documented risk acceptance.
- Monitoring secret usage for unusual geography, frequency, or time-of-day patterns so a compromised credential can be detected before lateral movement spreads.
- Moving credentials from source code into a managed secrets store and using access logging to support accountability and investigation.
- Tracking exceptions for legacy integrations where a control cannot yet be enforced, with compensating measures and a documented sunset date.
These patterns are especially relevant where identity sprawl is high: NHIs outnumber human identities by 25x to 50x in modern enterprises, and only 5.7% of organisations have full visibility into their service accounts, according to Ultimate Guide to NHIs — Key Challenges and Risks. For implementation detail, the risk treatment logic maps cleanly to the NIST Cybersecurity Framework 2.0 and its emphasis on governed, repeatable safeguards.
Why It Matters in NHI Security
Risk controls are where NHI governance becomes operational. Without them, a team may know that service accounts, API keys, and certificates are risky but still leave them overprivileged, unrotated, or stored in vulnerable locations. That gap is not theoretical: NHI security research from Oasis Security & ESG found that 72% of organisations have experienced or suspect a breach of non-human identities, and two-thirds have endured a successful cyberattack resulting from compromised NHIs. Those outcomes show why controls must be monitored continuously, not merely approved once.
In practice, good risk control design reduces the blast radius of secret exposure, constrains privilege escalation, and creates evidence for incident response and audit readiness. The same discipline also helps organisations avoid assuming that a login policy or a vault alone solves the problem. NHI risks are most visible in the gap between intended governance and actual runtime behavior, which is why controls need ownership, telemetry, and periodic recertification. Organisations typically encounter the need for explicit risk controls only after a secret leak, privilege abuse, or failed offboarding event, at which point the term becomes operationally unavoidable to address.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
OWASP Non-Human Identity Top 10 and OWASP Agentic AI Top 10 address the attack and risk surface, while NIST CSF 2.0, NIST Zero Trust (SP 800-207) and NIST AI RMF set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| NIST CSF 2.0 | GV.RM | Risk control is core to governed risk treatment and continuous oversight. |
| OWASP Non-Human Identity Top 10 | NHI-02 | Secret handling and exposure reduction are central NHI control concerns. |
| NIST Zero Trust (SP 800-207) | PA/PE/IA | Zero Trust requires continuous verification and limited trust for NHI access. |
| NIST AI RMF | Map/Measure/Manage | Risk controls should be mapped to hazards, measured, and governed over time. |
| OWASP Agentic AI Top 10 | A2 | Agentic systems need controls around tool access and execution authority. |
Assign owners, thresholds, and review cycles so each NHI control maps to a tracked risk decision.
Related resources from NHI Mgmt Group
Deepen Your Knowledge
Reviewed and updated by the NHIMG editorial team on August 28, 2026.
NHI Mgmt Group — the #1 independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org
