Itsm Framework

Download as docx, pdf, or txt
Download as docx, pdf, or txt
You are on page 1of 15

ITSM FRAMEWORK

Title of SOP ITSM Framework


Version 1.0
Prepared by Bhagwan Singh
Reviewed by
Approved by

SOP Review Yearly

FINOVA CAPITAL PRIVATE


LIMITED
Version Control Table

Versio Date Author Description


n

1.0 April-2024 Bhagwan Singh Initial Creation

1.0

1.0

1.0

1.0

1.0

Date of Next Revision April-2025

1
INDEX:
Section Section Title Page No.
No.
1 Objective 3
2 ITSM Toolkit 3
3 Incident/Request 5
Management Procedure
4 Problem Management 7
Procedure
5 Change Management 8
Procedure
6 Change Management 10
Roles and
Responsibilities
7 Incident & Problem 11
Management Process
Flow
8 Change Request 12
Workflow
9 Patch Management 13

2
1. Objective:

Objective of this document is to ensure the organization is following IT


service management process in line with industry standard framework like
ITIL for supporting its information systems and infrastructure, thus to ensure
the operational resilience of their entire IT environment including Disaster
Recovery Site.

2. ITSM Toolkit:

At its core, ITSM involves several key processes. These include Incident
Management, Problem Management, Change Management, Service Level
Management, and more. Each process contributes to an effective ITSM
strategy and helps organizations meet their IT objectives more efficiently.
2.1 Incident Management:
Incident Management manages IT service interruptions to restore normal
service operations quickly. It minimizes disruption and ensures that service
quality and availability are maintained.

2.2 Problem Management:


Problem Management is the process of managing the lifecycle of all
problems. The primary objective of this process is to prevent incidents and
minimize the impact of incidents that cannot be prevented.

2.3 Change Management:


Change Management is the process responsible for controlling the lifecycle
of all changes. Its primary objective is to enable beneficial changes with
minimum disruption to IT services.

2.4 Service Level Management:


Service Level Management involves designing, negotiating, and managing
service level agreements (SLAs). It ensures that all service management

3
processes, operational level agreements, and underpinning contracts are
appropriate for the agreed service level targets.

3. Incident/ Request Management Procedure

3.1 Incident/ Request Logging:


 An incident/ request is logged/ reported through ITSM Tool.
 Requester reports an issue/ service request through self-service portal
using specific templates, emails and phone calls with following details.

Field Summary
Category Broader group or classification of services.
Sub Narrower group or further classification of category.
Category
Item Specific area of problem.
Subject Title of incident/ request.
Description Provide detail as much as possible to help technician for
understanding the problem.
Impact Who has affected.
Urgency How quickly the incident is to be resolved.
Priority Severity of incident based on impact and urgency.
Assets Assets are involved in reported incident that are affected.

 Requester selects an incident/ request template based on nature of


incident/ request and submits the web form by choosing relevant
category and subcategory of the incident/ request.
 After submitting an incident/ request, a unique incident/ request ID
(ticket No.) is automatically generated against reported incident/
request through ITSM Tool for further reference and communication. As
soon as the incident/ request is logged, a notification is auto triggered
with detail to requester from ITSM Tool at his/ her email address as well
as on requester’s portal.

3.2 Incident/ Request Categorization and Prioritization:


 Incidents are categorized based on incident impact as follows:
a) Affects individual user.
b) Affects group of users
c) Affects business.
 Based on category & subcategory provided by employee, the incidents/
requests are initially prioritized and categorized automatically through
business rules in ITSM Tool. Later, technicians set priority and impact of
incident according to their analysis.

4
 The incidents are considered as Major, Medium, and Minor based on
the incident impact.

Severity Impact Urgency


Critical/ Major Affects business Urgent/ High/Critical
Medium Affects group of users Medium
Minor Affects user Low

3.3 Incident/ Request Assignment:


 All reported incident and request in the ITSM Tool get automatically
assigned to support desk technician within particular group of
technicians bases on business rule and technician auto assign rule
according to helpdesk categories. On assignment of the incident, a
notification is received to concerned technician.
 Incidents/ requests that has assigned wrongly to technician due to
miss-categorization by requester while logging an incident/ request,
are moved to right technician’s group updating the incidents after
being identified by the technician.
 Due to any reason, the incidents/ requests that are left unassigned, are
assigned manually to relevant technician’s group updating the
incidents/ request by Support desk coordinator.

3.4 SLA & Escalation Management:


 SLA is assigned to incident/ request based on parameters like
category, template etc.
 SLA involves “Estimated Response Time and Estimated Resolution
Time”.

Incident Severity Response Time


Critical/Major Within 1 Hrs.
Medium Within 2 Hrs.
Low Within 4 Hrs.

Incident Severity Resolution Time

5
Critical/Major Within 4 hrs
Medium Within 1 Business Day
Low Within 3 Business Day

 Once incident/ request is logged, SLA is started automatically against


that incident/ request.
 SLA is applicable on “OPEN” state only.
 Technician responses the incident/ request by adding progress note or
email against reported incident/ request to stop violation of response
SLA.
 In cases where SLA is about to breach or has been already breached,
the incident or request is automatically escalated to technician’s
reporting manager and their respective manager takes follow up with
respective technician for faster response and resolution time and gets
the problems resolved by involving themselves with incidents.

3.5 Incident/ Request Notification:


 In case of Critical and Major Incidents, the notifications are sent to
Management and Stakeholders.
 In case medium/low indents, tool base auto notification sent to user.

3.6 Incident/ Request Resolution:


 Resolution is considered resolved when the technician provides
temporary workaround or permanent solution to the reported incident/
request.
 On assignment of incident to technician starts working on assigned
incident.
 Technician gets access the requester’s asset remotely to troubleshoot
the problem. The technician visits requester’s location in case of
incident that is not resolved remotely,
 Technician investigates and diagnoses the problem. Based on the
complexity or dependency of the incident, Technician creates task into
incident and assigns task to other technician, if resolution requires the
contribution of multiple technicians from various verticals. Respective
tasks are closed by technician once they are resolved.
 After the problem is resolved, technician records the resolution given
against incident into resolution box of ITSM Tool for further reference
and marks the incident as resolved.

6
 Technician creates problem record from the incident to perform “Root
Cause Analysis” (RCA) in case of critical and major incidents,
communication to be sent to management team and impacted
business teams.

3.7 Incident/ Request Closure:


 All the resolved request is closed automatically on completion of user
survey or two days later.

4. Problem Management Procedure:


4.1 Problem Definition - A problem is an unknown cause of one or more
Incidents. The objective of Problem Management is to minimize the
impact of incidents and problems on business that are caused by errors
within the IT infrastructure, and to prevent recurrence of Incidents related
to these errors. Problem has two types: Proactive and Reactive.

4.2 Problem Detection:


 Problems are detected/ identified through incidents report, event
management tool.

Problem Logging, Categorization, Prioritization & Assignment:


 Problem is logged by technician only in ITSM Tool under problem
module based on the problem detection.
 Technician associates the related incident to a problem.
 Problem is categorized and prioritized by technician based on nature of
a problem.
 Problem gets assigned to technician according to selection done by
technician while logging the problem.

4.3 Notification and Announcement:


 Technician to whom the problem is assigned sends notification to Top
management (CEO, HODs) and stakeholders until and unless the
incident or problem is resolved.
Notification includes:
a) Incident Date, Time & Location.
b) Incident Type
c) Incident Impact
d) Estimated Resolution Time
e) Next Estimated Time (if more time is required)
f) Resolution
g) Total Down Time

7
 Technician makes announcement to inform all affected business users
about problem.

4.4 Problem Resolution & Closure:


 Technical team investigates and diagnosis the problem to discover the
root cause for root cause analysis (RCA) for critical incidents and
meanwhile, provides workaround (temporary solution) to restore
service ASAP and ensure business continuity.
 Once root cause is identified, the technical team fix the problem and
implements solution. If implementation requires any change,
technician creates a change request under change management
module.
 On resolution of problem, technician updates the problem ticket with
impact detail and RCA and resolves & closes the problem ticket.
 Problem is marked as “Known Error” by technician if same problem has
experienced before in past and have a workaround or know root cause.

5. Change Management Procedure

5.1 Change Submission and Logging:


 The change management team creates change request in ITSM Tool
based on one of the following:
a) An incident that causes a change.
b) A problem that results in a change.
c) A user requested for new change.

 Change management team associates an incident, request, and


problem to change request and submit a change request.

5.2 Change Planning:


 Once the change request is submitted, the change request moves
down on the planning stage.
 The change management team plans to carry out the successful
change implementation.
 Following things are documented to get necessary approval required to
implement change and convince stakeholders:
a) Change Type
b) Reason for change
c) Change Description
d) Change Impact & impact detail.
e) Change Risk
f) Change Priority
8
g) Change Category
h) Change Roll out plan.
i) Change Back out plan.
j) Change scheduled date and time, downtime for change if required.
k) Implementation planning
l) Role and Responsibility
m) Attachment, if any
5.3 Change Approval:
 When the planning is done, A change request goes to approvers for
approval.
 The approvers approve a change request.
 Once the necessary approvals are received, the change Manager
approves a change planning and then request moves down on the
implementation stage.

5.4 Change Implementation:


 In this stage, the implementers implement the change as per planning
by creating tasks.
 On completion of implementation activity, the implementers close the
tasks and approves a request to get it moved on next stage.
Note:
 If change request is related to IT INFRA, then change request moves
down on the change review stage according to defined IT-Infra change
workflow.
 If change request is related to IT SOFTWARE, then it moves down on
the change UAT stage according to defined IT-Software change
workflow.

5.5 Change User Acceptance Testing (UAT):


 UAT owner organizes and manages the testing of the associated
service with business user.
 Once testing is done by business user, UAT owner takes sign off from
business user.
 Post sign-off the CR will be moved to the release stage.

5.6 Change Release:


 Once the UAT is done, the IT change management Team fill up release
start date & time and request goes to approvers for approval to carry
out change release activity.

9
 The Change Manager and Change Approver approves a request and IT
change management team releases required changes on production
environment.
 On completion of release activity, IT change management team fill up
release end date and time. Hereafter, a change request moves down
on the change review stage.

5.7 Change Review:


 The change reviewer carries out change review process and ensure
that there is no deviation in the implementation and no issue is
observed.
 The change reviewer mentions his/ her observation and approves the
change review.
 In case of failure, the implementers perform change roll back activity
according to back out plan.
5.8 Change Closure:
 Once the change review is approved, the change moves down on the
close stage and gets closed automatically as per change workflow.

6. Change Management Role and Responsibilities:

Role Responsibilities
Change Requester Responsible for the creating change request.
Change Manager Responsible for the change process and ensures
that the change meets objectives and quality
standards.
Change Owner Responsible for the change assigned.
Change Implementer Responsible for implementing the change.
Change UAT Owner Responsible for organizing and managing the
testing of the associated service by
stakeholders.
Change Reviewer Responsible for analyzing the entire change
process and evaluates possible outcomes.
Change Line Manager Accountable for change's life cycle.
Change QA Approver Accountable for QA
Change Approver Responsible for determining the change
approval.

10
7. Incident & Problem Management Process Flow:

From Event From From From


Mgmt. Tool Web Form Phone Call Email

Incident
Identification

Incident
Logging

Incident
Categorization

Incident
Create Problem
Prioritization

Incident
Inform Management
Assignment

Enable
Collaboration Assigned Move to Correct
correctly?
Group

Impact Assessment
11
Service Request
RCA Request? Fulfillment
8. Change Request Workflow:

8.1 IT-Infra Request Workflow

8.2 IT-Software & Application Request Workflow

8.3 Application (Software) Change Management steps and


approving authority:
Change Management steps Approving authority
1. Change initiation Business Team, RCA,
Compliance
2. Discussion for requirement BA, Application Owner,
detailing Business Team
3. BRD preparation BA Team
4. BRD Signoff Business Team
5. Approval for changes System HOD
6. CR Raised to vendor for analysis IT Team

7. Efforts for the Change to be Vendor Team


shared
8. Cost and efforts approvals for CTO
change
9. Development, testing and patch Vendor
for UAT
10. UAT signoff Business User
11. Production Patch preparation, Vendor
sanity
12. Production patch movement CTO/Head
Approval

12
13. Functionality, validation/ testing End User, Business Team
in prod

9. Patch Management:

9.1 Purpose

This document is provided to define the requirements for identifying,


acquiring, installing, and verifying patches for products and systems. Patches
correct security and functionality problems in software and firmware.

9.2 Scope

This applies to all employees, contractors, subcontractors, consultants,


temporaries, guests, and any third party that uses Finova Capital Private
Limited information assets or information resources and services.

9.3 Responsibilities

Asset Manager:

 Responsible for implementing patch management controls in the


company.

ISMS Manager:

 Create documentation.
 Monitor the quality of the procedures done.

13
A patch is a software update comprising code inserted (i.e., patched) into an
executable program code. Typically, a patch is installed into an existing
software program. Patches are often temporary fixes between full releases of
a software package. Patches include, but are not limited to the following:

• Updating software;
• Fixing a software bug;
• Installing new drivers;
• Addressing new security vulnerabilities;
• Addressing software stability issues.

The suggested action items for Patch Management are:

 Keep the inventory and all the systems, including the operating
systems and software versions, physical location, IP addresses, etc. up
to date.
 Assess the risk and vulnerability and classify the risk accordingly. Find
servers and systems which are vulnerable and company-critical.
 Evaluate all missing software updates according to the risk they pose.
Missing software updates that pose an unacceptable risk to Finova
Capital Private Limited resources must be implemented within a
commensurate time with the risk.

9.4 Laptops

 Every employee’s responsibility is to monitor notifications about new


updates available for their OS and install them on their laptops.
Automated updates should be enabled on each employee’s laptop.

9.5 Servers

• The availability of OS/Network Device/Database/Middleware and other


patches provided by third parties should be monitored to ensure timely
updates.
• Any upgrade must be tested before deployment.

9.6 Patch Deployment Process:

1. AWS System Manager regular scans for pending patches.


2. IMS team list out all pending patches with patch release date CVE
score and other details.
3. Do the risk assessment for patch deployment, any adverse impact on
hosted business application.

14
4. Raise a CR with list of pending patches with Information Asset details.
5. Take approval form Head of IT to deploy patches.
6. Plan out for patch deployment, system downtime approval from
respective application owner, backup plan in case patch deployment
fails etc.
7. First deploy patches on UAT or Pre-Prod environment, after 15 days of
observation deploy in production environment.
8. For any critical Zero Day patch can be deployment directly or as per
criticality.
9. All the security patches should be deployed in both environment within
60 Days.

9.7 Patch Exception Management:

Patches that Finova IT want to explicitly include or exclude from a specific


managed server, along with a justification/risk acceptance reason for why
the exception exists.

• IT team will create a request for patch exception with name of patch,
specific server details with Server role, justification why we are not
deploying patch and risk assessment of patch exception.
• On the basis of risk acceptance by Head of IT, an exception will be
created in exception repository.

15

You might also like