Attackers increasingly use the same paths IT operations uses every day, the help desk, the admin console, the automation account and the change window, so the security of an organisation often depends on how disciplined its operations are. This model describes five levels of IT operations security maturity, from Ad hoc to Optimised, across six dimensions: change control, operational privileged access, runbooks and procedures, configuration and backup integrity, service desk identity assurance, and evidence and monitoring. Each level has observable indicators, and the page includes self-assessment questions and the steps to move up. It is written for heads of IT operations, infrastructure and platform leads, service desk managers and the CISOs who depend on them. It uses the NHI Mgmt Group five-level scale and links to the detailed guides for each dimension.
Key takeaways
- Operations is a control surface. Change, admin access, the service desk and automation accounts are where operational convenience and attacker opportunity meet.
- Level 3 means every privileged action is traceable. At Defined, privileged work runs through documented runbooks, named identities and tickets, and the evidence exists without being reconstructed.
- The service desk is an identity control. Credential resets and MFA re-enrolment are privileged operations, and caller verification decides whether they are safe.
- Machine identities in ops tooling hold maturity back. Scripts, schedulers, RMM agents and config collectors running under shared or ownerless accounts keep many organisations below Level 4.
- Maturity is proven by reconciliation. Higher levels compare what changed with what was approved, automatically, and treat every mismatch as a potential incident.
The five levels
| Level | Name | Description |
|---|---|---|
| 1 | Ad hoc | Changes are made directly by whoever has access. Administrators use standing privileged accounts, some shared. Procedures live in people's heads or personal notes. Device and platform configurations are backed up inconsistently. The service desk resets passwords and MFA on a caller's word. Evidence is assembled after the fact, if at all. |
| 2 | Developing | A change process exists for major changes, but emergency and "small" changes bypass it. Admin accounts are separate from daily accounts and most use MFA. Key procedures are written in a wiki without identity or approval fields. Backups of critical systems run but restores are rarely tested. The service desk has a verification script that relies on information an attacker can find. |
| 3 | Defined | All production changes go through risk-based change control with security review triggers. Privileged runbooks name the execution identity, approval and evidence. Privileged access for Tier 0 systems is just in time from privileged access workstations. Configurations are archived securely and diffed. Credential resets for privileged users need strong verification. Admin logs reach the SOC. |
| 4 | Managed | Changes are reconciled automatically against tickets and unmatched changes are investigated. Standing privilege is largely removed and every privileged session is linked to a ticket. Automation and ops tooling run under owned, scoped machine identities with rotated credentials. Restores and runbooks are tested on a schedule. Metrics are reported to leadership. |
| 5 | Optimised | Infrastructure and configuration are managed as code with policy checks before deployment, and drift is corrected automatically after triage. Approval gates are built into automation and AI agent workflows. Incident lessons, red team findings and near misses change runbooks and controls within a set period. Operational security metrics drive investment. |
The six dimensions
| Dimension | Level 2 indicator | Level 3 indicator | Level 4 to 5 indicator |
|---|---|---|---|
| Change control | Process for major changes; emergency changes undocumented | All production change ticketed and risk rated; emergency changes reviewed after the event | Automated reconciliation of changes against tickets; policy as code in pipelines |
| Operational privileged access | Separate admin accounts with MFA | Just-in-time access for Tier 0; privileged access workstations; no shared admin accounts | Near-zero standing privilege; every session linked to a ticket and recorded |
| Runbooks and procedures | Written procedures without identity or approval fields | Privileged runbooks to a standard with owner, tier, identity, approval and evidence | Runbooks tested on schedule; codified runbooks with approval gates |
| Configuration and backup integrity | Scheduled backups of critical systems | Encrypted, access-controlled config archives; restore tests for Critical services | Immutable or isolated backups; drift detection and integrity checks before restore |
| Service desk identity assurance | Verification script using personal details | Stronger verification for privileged users and MFA resets; resets logged and reviewed | Verification through out-of-band or identity-proofing methods; alerts on unusual reset patterns |
| Evidence and monitoring | Logs collected for some admin systems | Admin and change logs in the SIEM; service register links services to owners and identities | Continuous controls monitoring; evidence produced automatically for audit |
Dimension to framework mapping
| Dimension | NIST SP 800-53 Rev. 5 | NIST CSF 2.0 |
|---|---|---|
| Change control | CM-3 Configuration Change Control, CM-4 Impact Analyses | PR.PS-01 |
| Operational privileged access | AC-6 Least Privilege, AC-5 Separation of Duties | PR.AA-05 |
| Runbooks and procedures | SA-5 System Documentation | PR.PS-01 |
| Configuration and backup integrity | CM-2 Baseline Configuration, CP-9 System Backup | PR.DS-11, RC.RP-03 |
| Service desk identity assurance | IA-5 Authenticator Management | PR.AA-02 |
| Evidence and monitoring | AU-6 Audit Record Review, Analysis, and Reporting, AU-12 Audit Record Generation | DE.CM-09 |
Self-assessment questions
- Change: Can you list last month's production changes that had no ticket? If you cannot produce the list, you are at Level 2 or below.
- Privilege: How many accounts hold standing Tier 0 rights today, and who reviewed them last?
- Runbooks: For your ten most dangerous operational tasks, does each runbook name the identity, approver and evidence?
- Configuration: Where are network and platform configuration backups stored, who can read them, and when was a restore last tested?
- Service desk: How does the service desk verify a caller asking for an MFA reset on an administrator account, and could an attacker answer those questions from public information?
- Machine identities: Does every scheduler, automation account, RMM agent and config collector have a named owner and a rotated credential?
- Evidence: If an auditor picked a privileged change from last quarter, how long would it take to show the request, approval, session and outcome?
Where identity fits
Most of this model is about identity in operations. Human administrators need separate, just-in-time privileged access; see the JIT Access Guide. Ops tooling runs on non-human identities that often hold more privilege than any person: patch and RMM agents, backup service accounts, configuration collectors, CI/CD deployers and the integration users of the ticketing platform. Give each one an owner, a scope and a rotation schedule, and record it against the service it supports in the Service Security Register Template. The service desk is the human front door to identity: in the MGM Resorts breach, the attackers claimed that a call to the IT help desk impersonating an employee led to administrator access (MGM has not confirmed these details), which is why caller verification sits in this model.
Moving up a level
From Level 1 to Level 2
- Separate admin accounts from daily accounts and enforce MFA on them.
- Introduce a basic change record for production and a weekly change review.
- Write down the top ten privileged procedures, even in simple form.
- Schedule backups of critical systems and device configurations.
From Level 2 to Level 3
- Adopt a runbook standard with identity, approval and evidence fields. See Privileged Operations Runbooks.
- Route all production change through risk-based change control, including emergency changes. See Change Management Security.
- Move Tier 0 administration to just-in-time access from privileged access workstations.
- Secure configuration archives and diff them. See the Network Configuration Backup and Change Control guide.
- Strengthen service desk verification for privileged users and MFA resets.
From Level 3 to Level 4
- Reconcile changes against tickets automatically and send mismatches to the SOC.
- Bring ops tooling identities under ownership, vaulting and rotation.
- Link every privileged session to a ticket and runbook ID.
- Test restores and Tier 0 runbooks on a schedule and report results.
From Level 4 to Level 5
- Manage configuration as code with policy checks before deployment.
- Build approval gates into automation and AI agent workflows. See Dual control and four-eyes approval for privileged and agent actions.
- Feed incident and red team lessons into runbooks and controls within a set period.
Small and large organisations: A small IT team can reach Level 3 with a ticketing tool, a password vault with checkout, a runbook template and vendor-native backups. Level 4 and 5 usually need PAM, configuration management tooling and SIEM integration, which suit larger or regulated estates.
Metrics that show maturity
| Metric | Level 3 expectation | Level 4 to 5 expectation |
|---|---|---|
| Production changes without a ticket | Found and reviewed monthly | Detected automatically, near zero |
| Standing Tier 0 accounts | Known, small and reviewed | Near zero outside break-glass |
| Privileged runbooks meeting the standard | All Tier 0 | All Tier 0 and Tier 1, tested yearly |
| Ops tooling identities with owner and rotation | Inventoried | 100% |
| Successful restore tests for Critical services | Annual | Quarterly, with results reported |
| Privileged resets with strong verification | Policy in place | Measured and audited |
Common failure patterns
- Emergency as the normal route: Most changes are labelled emergency to skip review, and nobody reviews them afterwards.
- PAM bought, standing access kept: The vault is deployed but runbooks still tell engineers to use permanent admin accounts.
- Automation outside the model: Human admin access is tightly controlled while scripts and agents run as domain admin.
- Backups that cannot be trusted: Backups exist, but nobody has tested a restore or checked whether the backup system's own credentials are isolated. See the Backup Identity Isolation Guide.
- Help desk verification by public facts: Callers are verified with employee ID or manager name, which attackers can find.
Practitioner checklist
- Score each of the six dimensions honestly, with evidence, and record the lowest as your overall level.
- Remove shared admin accounts and separate admin from daily accounts.
- Adopt a privileged runbook standard and apply it to Tier 0 first.
- Route every production change through risk-based change control.
- Protect and test configuration and system backups.
- Strengthen service desk verification for privileged resets.
- Give every ops tooling identity an owner, scope and rotation schedule.
- Report the six metrics quarterly and reassess annually.
Standards and references
- NIST: SP 800-53 Rev. 5
- NIST: Cybersecurity Framework 2.0
- NCSC: Secure System Administration
- NCSC: Use Privileged Access Management
- NCSC: Cyber Assessment Framework Principle A3 Asset Management
- CISA: Enhanced Visibility and Hardening Guidance for Communications Infrastructure
Related NHI Mgmt Group resources: PAM Maturity Model · Tiered Administration and Enterprise Access Model Guide · Patch Management Guide · AI Agents in the IT Service Desk