vaayaa Inclusive Education
Technical risk assessment

IT Service Management and Enterprise Operations Risk Assessment: Service, Access and Recovery Controls

A worked example of how an enterprise IT operations team identifies, scores and controls the risks that threaten service availability, data confidentiality and integrity, and recovery from disruption.

Updated November 2026 8 hazards assessed Review every 6 months Highest risk: Critical to Medium
See the IT Service Management and Enterprise Operations course

Executive summary

This assessment shows how an enterprise operations team can find, rate and control the risks that matter most to service availability, data confidentiality and integrity, and recovery. Eight risks were chosen because they are plausible in everyday service management work. Identity compromise and unpatched or misconfigured systems carry the highest natural scores, and both can cause wide harm. Each risk is scored before controls and again after existing and added controls. Most risks fall to Medium or Low once the proposed controls are in place, but identity compromise and third-party exposure remain Medium because the impact stays serious. The first actions are multi-factor sign in for administrators, a baseline configuration check, a tested full service restore and a logging check for critical systems. The enterprise is a teaching example, so every score illustrates method, not a real organization.

Focus area
IT service management and enterprise operations
Setting
Internal IT service desk and operations team supporting a mid-sized enterprise with hybrid infrastructure and third-party hosting
Method
Five by five likelihood and impact risk register

Scope

This assessment covers the service management and operations function of a mid-sized enterprise, including incident, change, problem, configuration, request and continuity processes, plus the infrastructure, identity, logging and third-party services that support them. It does not cover a specific product, vendor or site. Assumptions: jurisdiction is not specified, the estate is a mix of on premises and cloud systems, and all scores are for teaching only.

Context

The operations team has a service desk, infrastructure engineers, an identity and access administrator and a service owner for each business application. Work is recorded in an IT service management tool linked to a configuration database that lists servers, applications, network devices and their dependencies. Backups and part of the hosting are provided by a managed service provider under a contract with service levels. Endpoints are managed centrally, and security events are sent to a shared log platform. Each risk is scored before controls to show its natural level, then again after existing controls and the additional controls proposed, so the student can see how treatment changes the picture.

Objectives, assets and stakeholders

The objective is to keep services available and accurate, protect the confidentiality and integrity of data, meet privacy and record duties, and recover quickly when something fails. The assets in scope are servers, network devices, cloud services, the configuration database, the service management tool, backups, identity accounts, logs and the personal data held in business applications. Stakeholders include service owners, business users, the service desk, security staff, auditors, customers, data subjects and the managed service provider. Clear roles matter: every risk has one owner role, and the service management lead reports the register to the operations board each quarter.

Risk matrix: before and after controls

Each cell shows hazard numbers placed by likelihood and impact. Compare the two grids to see how controls move each hazard.

Before controls

Inherent risk

Risk before controls: rows are likelihood from almost certain to rare, columns are impact from insignificant to catastrophic. Cells list hazard numbers.
1
Insignificant		 2
Minor		 3
Moderate		 4
Major		 5
Catastrophic
5 Almost certain
4 Likely Likelihood 4, impact 4, score 16, high: H01 H03 Likelihood 4, impact 5, score 20, critical: H02
3 Possible Likelihood 3, impact 3, score 9, medium: H07 Likelihood 3, impact 4, score 12, high: H04 H05 Likelihood 3, impact 5, score 15, high: H06
2 Unlikely Likelihood 2, impact 5, score 10, high: H08
1 Rare

After controls

Residual risk

Risk after controls: rows are likelihood from almost certain to rare, columns are impact from insignificant to catastrophic. Cells list hazard numbers.
1
Insignificant		 2
Minor		 3
Moderate		 4
Major		 5
Catastrophic
5 Almost certain
4 Likely
3 Possible
2 Unlikely Likelihood 2, impact 2, score 4, low: H07 Likelihood 2, impact 3, score 6, medium: H01 H03 H04 H05 H08 Likelihood 2, impact 4, score 8, medium: H02 H06
1 Rare
  • Low 1 to 4
  • Medium 5 to 9
  • High 10 to 16
  • Critical 17 to 25

Hazard register

A summary first, then the detail for each hazard.

Summary of hazards with scores before and after controls
No.HazardBeforeAfterOwner
H01 Unpatched systems and misconfiguration 16 High 6 Medium Infrastructure operations manager
H02 Identity compromise and unauthorized access 20 Critical 8 Medium Identity and access manager
H03 Phishing and malware on endpoints 16 High 6 Medium Endpoint security lead
H04 Insider misuse and privileged change error 12 High 6 Medium Change manager
H05 Third-party outage or breach 12 High 6 Medium Supplier relationship manager
H06 Major service disruption and failed recovery 15 High 8 Medium Service continuity manager
H07 Logging gaps and slow incident response 9 Medium 4 Low Security operations lead
H08 Privacy and records compliance breach 10 High 6 Medium Data protection officer
H01

Unpatched systems and misconfiguration

Technology and data Before 16 After 6

Servers, network devices and applications run out of date software or with default or weak settings, so known weaknesses can be exploited and changes made outside the process cause outages.

Who or what is affected: Service desk, infrastructure engineers and business users

Causes

Manual builds, unclear patch ownership and legacy systems that cannot be patched quickly.

Consequences

Compromise of systems, unplanned outages, failed audits and costly emergency changes.

Existing controls

  • Patches for critical systems are applied monthly after testing.
  • Standard build templates are used for new servers.

Control gaps

Patch status is reported for servers but not for network devices or some cloud services.

Additional controls

  • Prevent: Apply secure baseline configurations to every build and block changes that drift from the baseline.
  • Detect: Run weekly configuration scans and raise a ticket for each system that falls outside its baseline.
Likelihood 4 x impact 4 before; 2 x 3 after Owner: Infrastructure operations manager Target: Within 30 days Early warning: Critical vulnerabilities older than 14 days on production systems.
H02

Identity compromise and unauthorized access

Technology and data Before 20 After 8

Stolen or shared credentials, excessive administrator rights and stale accounts let an attacker or a former employee reach systems and data that the role does not need.

Who or what is affected: Business users, administrators, customers and data owners

Causes

Shared administrator passwords, role creep over time and joiner, mover and leaver steps that are not completed.

Consequences

Data theft, unauthorized changes, service outage and loss of customer trust.

Existing controls

  • Users sign in with individual accounts and password rules apply.
  • Administrator accounts are separate from daily user accounts.

Control gaps

Access reviews happen only when a manager asks for one, so old rights remain in place.

Additional controls

  • Prevent: Require multi-factor sign in for all administrators and remote access, and remove standing privileged rights.
  • Detect: Review privileged access and dormant accounts each month and record every removal.
Likelihood 4 x impact 5 before; 2 x 4 after Owner: Identity and access manager Target: Within 30 days Early warning: Privileged accounts that have not been reviewed within the last 90 days.
H03

Phishing and malware on endpoints

Technology and data Before 16 After 6

Staff are tricked into opening malicious links or attachments, or run software that spreads through the network, locking files or stealing credentials before anyone notices.

Who or what is affected: All staff, the service desk and shared file stores

Causes

Convincing phishing messages, remote working outside protected networks and rights that let software install freely.

Consequences

Encrypted or lost files, credential theft, lateral movement and days of disrupted work.

Existing controls

  • Endpoints run managed anti-malware with automatic signature updates.
  • Email filtering blocks known malicious attachments.

Control gaps

Phishing tests are run once a year and results are not linked to individual training.

Additional controls

  • Prevent: Restrict local administrator rights and block macros from files received by email.
  • Respond: Isolate infected devices from the network and reset credentials used on them within an hour.
Likelihood 4 x impact 4 before; 2 x 3 after Owner: Endpoint security lead Target: Within 45 days Early warning: Repeated user reports of suspicious messages from the same sender or domain.
H04

Insider misuse and privileged change error

People Before 12 After 6

An employee or contractor with legitimate rights makes an unauthorized change, copies data for personal use or makes a careless error on a live system that affects many users.

Who or what is affected: Business users, customers and colleagues in operations

Causes

High workload, pressure to fix problems quickly and rights that exceed what the job needs.

Consequences

Data loss or exposure, outages, disciplinary action and legal exposure for the enterprise.

Existing controls

  • Changes to production need a recorded approval.
  • Staff sign an acceptable use policy when they join.

Control gaps

Emergency changes are approved after the event, and the review is not always completed.

Additional controls

  • Prevent: Require a second engineer to approve every change to production databases and network rules.
  • Detect: Alert on bulk data exports and on changes made outside an approved change window.
Likelihood 3 x impact 4 before; 2 x 3 after Owner: Change manager Target: Within 60 days Early warning: Emergency changes that were not reviewed within two working days.
H05

Third-party outage or breach

Supplier Before 12 After 6

A managed service provider, cloud host or software supplier suffers an outage, a security breach or a failed backup, and the enterprise has limited visibility of the cause or the timing of recovery.

Who or what is affected: Service owners, business units and customers

Causes

Shared hosting, dependence on one provider and limited control over the supplier's staff and tools.

Consequences

Extended outage, data exposure, contract disputes and loss of service credits that do not cover the real cost.

Existing controls

  • Contracts include service levels and a notice period for incidents.
  • Key suppliers provide an annual summary of their controls.

Control gaps

Supplier reports are reviewed once a year and not compared with live service data.

Additional controls

  • Prevent: Require suppliers to disclose security incidents within a set period and to share audit evidence.
  • Recover: Keep an exit and recovery plan for each critical supplier, tested at least once a year.
Likelihood 3 x impact 4 before; 2 x 3 after Owner: Supplier relationship manager Target: Within 60 days Early warning: A critical supplier misses two consecutive service level reports.
H06

Major service disruption and failed recovery

Operational Before 15 After 8

A hardware failure, power loss or bad release takes a critical service offline, and the recovery steps are untested, out of date or dependent on people who are unavailable.

Who or what is affected: Business units, customers and service desk staff

Causes

Single points of failure, aging equipment and recovery plans that depend on named individuals.

Consequences

Lost revenue, missed deadlines, data loss and damage to service reputation.

Existing controls

  • Critical services have a documented recovery procedure.
  • Backups run each night and are stored off site.

Control gaps

Restores are tested for files but not for complete services with their dependencies.

Additional controls

  • Recover: Test a full service restore against the recovery time objective each quarter and record the result.
  • Prevent: Add redundancy for power, storage and network paths for the most critical services.
Likelihood 3 x impact 5 before; 2 x 4 after Owner: Service continuity manager Target: Within 90 days Early warning: A restore test that exceeds the recovery time objective for a critical service.
H07

Logging gaps and slow incident response

Operational Before 9 After 4

Logs are missing, incomplete or not reviewed, and incidents are classified late, so the team cannot prove what happened or contain the event before it spreads.

Who or what is affected: Security staff, service desk, auditors and affected business users

Causes

Logging not switched on for some applications, too many alerts and unclear ownership of incident triage.

Consequences

Longer breach dwell time, weak evidence for investigation and slow restoration.

Existing controls

  • Core servers and firewalls send logs to a central platform.
  • Major incidents follow a written escalation path.

Control gaps

Cloud and endpoint logs are not yet part of the central platform.

Additional controls

  • Detect: Set alerts for failed logins, new administrator accounts and disabled logging on key systems.
  • Respond: Run a tabletop exercise each half year to test the incident response roles and handoffs.
Likelihood 3 x impact 3 before; 2 x 2 after Owner: Security operations lead Target: Within 90 days Early warning: Critical systems that have sent no logs for more than 24 hours.
H08

Privacy and records compliance breach

Legal and compliance Before 10 After 6

Personal data is kept longer than needed, sent to the wrong recipient or stored outside approved locations, and records required by law or contract are lost or cannot be produced on request.

Who or what is affected: Customers, employees, data subjects and regulators

Causes

Copies of data in email and spreadsheets, unclear retention rules and records held by suppliers.

Consequences

Regulatory penalties, legal claims, forced disclosure and loss of customer trust.

Existing controls

  • A data protection policy assigns owners for personal data.
  • Retention periods are listed for main record types.

Control gaps

Retention is not enforced automatically, so old records remain in some systems.

Additional controls

  • Prevent: Classify data sets by sensitivity and block personal data from unapproved storage locations.
  • Respond: Maintain a written breach notification procedure and rehearse it with the legal team.
Likelihood 2 x impact 5 before; 2 x 3 after Owner: Data protection officer Target: Within 60 days Early warning: Data sets held beyond their approved retention period in any system.

Rating method and evaluation

Each risk is rated on two five-point scales. Likelihood runs from Rare to Almost certain, and impact runs from Insignificant to Severe. Multiplying the two gives a score from 1 to 25, which falls into one of four bands: Low from 1 to 4, Medium from 5 to 9, High from 10 to 16 and Critical from 17 to 25. The score is a guide for ordering work, not a measurement. Inherent risk is the score before any controls. Residual risk is the score after the existing controls and the additional controls, and it can never be higher than the inherent score. Impact is judged on service downtime, data exposure, cost to correct, legal duty and harm to customers, and a risk is never rated down only because it has not yet happened. Anything still High needs senior attention and a dated plan, anything Medium needs routine controls with a named owner, and anything Low is accepted and watched. Team members who run the systems should challenge the ratings, and each rating is reviewed whenever a warning indicator reaches its threshold or a major change is made.

Likelihood, impact and rating bands

Likelihood

  • 5 Almost certain: Expected to happen in most circumstances.
  • 4 Likely: Will probably happen in many circumstances.
  • 3 Possible: Could happen at some time.
  • 2 Unlikely: Not expected, but it could happen.
  • 1 Rare: Only in exceptional circumstances.

Impact

  • 1 Insignificant: No lasting effect. Handled within routine work.
  • 2 Minor: Small effect that is quickly corrected.
  • 3 Moderate: Noticeable effect that needs managed effort to correct.
  • 4 Major: Serious effect on people, delivery or reputation.
  • 5 Catastrophic: Severe or lasting effect that threatens the whole activity.

Bands (likelihood x impact)

  • Low (1 to 4): Accept and monitor.
  • Medium (5 to 9): Manage with routine controls.
  • High (10 to 16): Senior attention and a treatment plan.
  • Critical (17 to 25): Act first. Do not proceed until reduced.

Monitoring, escalation and review

Review this assessment every 6 months, and sooner when an indicator below reaches its threshold.

Early-warning indicators and escalation thresholds
Indicator to watchEscalate when
Critical vulnerabilities older than 14 days on production systems.Escalate to the infrastructure operations manager when any item passes 14 days, and to the operations board after 30 days.
Privileged accounts not reviewed within the last 90 days.Escalate to the identity and access manager at once, and suspend any account with no owner confirmation within a week.
Emergency changes not reviewed within two working days.Escalate to the change manager when any review is late, and to the service management lead if more than three are open.
Critical systems that have sent no logs for more than 24 hours.Escalate to the security operations lead immediately, and to the incident manager if the gap is not explained within four hours.
Critical supplier service level reports missed for two consecutive periods.Escalate to the supplier relationship manager at once, and to the service owner and procurement lead if the miss continues for a month.

Contingency arrangements

If a serious event occurs, such as a confirmed account compromise, a ransomware style infection or a major outage, the incident manager declares the event and opens a bridge call. The security lead isolates affected systems and disables compromised accounts. The continuity manager starts the recovery plan for the affected service, using the latest verified backup. The data protection officer assesses any personal data exposure and decides on notifications through the legal route for the relevant jurisdiction. Business owners are told what they need to know early, in plain terms.

Prioritized action plan

  1. Enforce multi-factor sign in and remove standing privileged rights, owner identity and access manager, within 30 days.
  2. Apply secure baselines and run weekly configuration scans, owner infrastructure operations manager, within 30 days.
  3. Test a full restore of one critical service against its recovery time objective, owner service continuity manager, within 90 days.
  4. Bring cloud and endpoint logs into the central platform with alerts for key events, owner security operations lead, within 90 days.
  5. Add incident and breach exercises and a supplier exit plan for critical suppliers, owner supplier relationship manager, within 60 days.

Conclusion

Reliable operations depend on a few steady habits: strong identity controls, a baseline for every build, tested recovery, complete logs and clear change approval. The highest scores sit with identity compromise, unpatched systems and disruption, and each has actions that bring the residual score down. Treat the register as a living record, review it on the stated cycle, and seek qualified security, privacy and legal advice for any real incident or compliance question.

Assumptions and limitations

Assumptions

  • The enterprise runs an incident, change, problem and request process based on general IT service management practice.
  • Systems are a mix of on premises servers and cloud services, with a managed service provider for backups and hosting.
  • Jurisdiction and sector rules are not specified, so legal and privacy duties are described in general terms only.

Limitations

  • The scores are examples for learning and do not describe any real organization, system or incident.
  • Security, privacy and continuity requirements differ by sector and country and change over time, so specialist review is needed.
  • This is educational content and does not replace a formal site-specific assessment or licensed security advice.

Related frameworks to study

  • IT service management practices such as the ITIL service value system
  • NIST Cybersecurity Framework functions of identify, protect, detect, respond and recover
  • Configuration management database concepts for dependency mapping
  • Hierarchy of controls for ranking treatment options
  • Three lines model of risk ownership

Technical Risk Assessment

China, India, United States, Indonesia, Pakistan, Nigeria, Brazil, Bangladesh, Russia, Japan, Mexico, Philippines, Vietnam, Egypt, Turkey, Germany, United Kingdom, France, Italy, Canada, South Korea, Australia, Spain.

For Learning Reference Only: This assessment demonstrates how risk assessment principles are applied in a practical setting, providing a useful reference for learning and understanding. Actual assessments may be adapted to suit specific site conditions and circumstances.

Keep learning

Study the subject behind this assessment.

IT Service Management and Enterprise Operations course Read the best practices for this course

More Technical risk assessments

Hourly Active: 35,661 Learners