Itsm Framework
Itsm Framework
Itsm Framework
1.0
1.0
1.0
1.0
1.0
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:
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.
3
processes, operational level agreements, and underpinning contracts are
appropriate for the agreed service level targets.
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.
4
The incidents are considered as Major, Medium, and Minor based on
the incident impact.
5
Critical/Major Within 4 hrs
Medium Within 1 Business Day
Low Within 3 Business Day
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.
7
Technician makes announcement to inform all affected business users
about problem.
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.
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:
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:
12
13. Functionality, validation/ testing End User, Business Team
in prod
9. Patch Management:
9.1 Purpose
9.2 Scope
9.3 Responsibilities
Asset Manager:
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.
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
9.5 Servers
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.
• 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