Password Reset an Incident or a Service Request? It’s Monday morning. Your phone rings, and on the other end is Sarah from accounting, locked out of her system after mistyping her password three times over her first cup of coffee.
Your service desk agent opens a ticket, but then pauses. Should this be logged as an incident or a service request?
It seems like a simple question, but this seemingly trivial decision has sparked heated debates in IT service management forums for years, revealing deeper truths about how we think about IT service delivery.
The Debate That Won’t Die
Walk into any ITIL training session, and you’ll likely witness this scenario unfold. About half the room will confidently assert that password resets are service requests, citing ITIL definitions with precision.
The other half will argue just as passionately that they’re incidents, because the user can’t access their services. The instructor might even pull up a chair, put their hand over their face, and wonder where the discussion went sideways.
This isn’t just academic hair-splitting. The way organizations classify password resets has real consequences:
Budget decisions – Metrics inform how resources are allocated
Response times – Classification shapes how quickly users get help
Infrastructure perception – Influences whether your IT looks stable or fragile to executive leadership
The Impact on Perception:
Organization A: 500 monthly password resets classified as incidents → Systems appear to be failing constantly
Organization B: Same resets classified as service requests → Stable infrastructure with high demand for routine support
To understand this evolution, we must begin with the definitions that have guided IT service management for decades.
Core Definitions
Classification
ITIL Definition
Key Characteristic
Incident
An unplanned interruption to an IT service or a reduction in the quality of that service
Unplanned – Nobody scheduled the failure
Service Request
A formal request from a user for something to be provided
Planned/Expected – Routine activities following standard procedures
ITIL Examples of Service Requests:
Password resets
Requests for information or advice
Installing workstations for new users
The Reality Gap
The distinction seems clear on paper, but reality is messier. When Sarah can’t log in, isn’t her service interrupted? From her perspective, her ability to work has stopped just as surely as if the email server had crashed.
This is where the philosophical debate begins, and it’s been raging since ITIL Version 2 introduced the concept of Request Fulfillment as a separate process.
The ITIL 2 Era: When Process Separation Created Confusion
ITIL Version 2, released around the year 2000, organized IT service management into ten core processes split between Service Support and Service Delivery. This version made a clear distinction between fixing broken things and providing standard services, but the implementation often led to unintended consequences.
Why Organizations Got It Wrong
Many organizations during this era treated password resets as incidents simply because their tooling made it easier:
Mature incident management modules in ServiceNow and other ITSM platforms
Less developed service request functionality in early systems
Awkward user experience – Catalog items could be added to shopping carts, making it odd to “shop” for a password reset
The Consequences
This led to a pragmatic but problematic approach:
Organizations classified password resets based on convenience rather than correctness
Skewed metrics that misrepresented system stability
Confusion about what incident counts actually meant
The Gray Zone: When Exceptions Prove the Rule
Here’s where the story gets interesting. While most password resets should be service requests, there are legitimate exceptions that reveal the sophistication required in modern IT service management.
Legitimate Incident Scenarios
Scenario 1: Automated Password Change Breaks Service
A server application suddenly stopped working
Investigation revealed: Administrator account password automatically changed by group policy rollout
Application’s analytics component tied to this account
Result: Entire service failed due to credential change
Classification: Incident (technical failure caused the problem, not user error)
When a user forgets their password, the security system is working exactly as designed by rejecting the login. Nothing is broken. But when the password reset system itself fails, preventing all resets, that becomes an incident because the system that’s supposed to provide the service isn’t functioning.
The Metrics That Matter
The classification decision has profound implications for how organizations understand their IT operations. Records aren’t kept merely for compliance purposes but to facilitate governance and decision-making.
Need to invest in “fixing and stabilizing” infrastructure
Properly classified as service requests
True nature of demand on IT revealed
Opportunities exist for automation, self-service, and user education
What Proper Classification Reveals
Service Request Classification Shows:
Opportunities for automation
Need for self-service portals
Better user training requirements
IT supporting healthy level of business activity (not firefighting)
Critical Budget Decisions:
Infrastructure replacement vs. automated password reset tools?
New servers vs. improved authentication systems?
Stability investments vs. innovation investments?
The ITIL 3 Refinement: Lifecycle Thinking
ITIL Version 3, released in 2007 and refined in 2011, represented a significant evolution in thinking. Rather than just presenting processes as separate activities, ITIL 3 introduced a service lifecycle approach.
The Five Service Lifecycle Stages
Service Strategy
Service Design
Service Transition
Service Operation
Continual Service Improvement
Impact on Password Reset Classification
This lifecycle perspective added important context:
Not enough to simply categorize something correctly
Organizations needed to think about how that activity fit into the broader service lifecycle
Password resets became an opportunity to think strategically about identity and access management as a service
ITIL 3 Best Practices
Crystallized Guidelines:
Password resets were service requests unless a technical failure caused the access issue
Organizations should implement self-service options
Routine requests were perfect candidates for automation
The Complexity Challenge
ITIL 3 expanded from 10 processes (Version 2) to 26 processes, making it:
✓ More comprehensive
✗ More complex
Some organizations lost in process documentation
Sometimes lost sight of fundamental goal: delivering value to users
The ITIL 4 Revolution: Value Streams Over Rigid Processes
When ITIL 4 arrived in 2019, it represented not just an update but a fundamental reimagining of IT service management. The framework shifted from a pure process focus to a more holistic view centered on value creation and flexibility.
Key Changes in ITIL 4
From
To
Why It Matters
“Processes”
“Practices”
Acknowledges that Agile, DevOps, and Lean have reshaped modern IT
Process focus
Value creation focus
ITIL integrates with modern approaches rather than competing
Rigid adherence
Flexible frameworks
Successful service delivery about achieving outcomes, not following processes
The Service Value System
ITIL 4 introduced the Service Value System, which shows how all components of an organization work together to create value. It emphasizes:
Value co-creation between service providers and users
Achieving outcomes that matter to stakeholders
Flexibility over rigidity
Reframing the Password Reset Question
For password resets, this evolution means thinking beyond classification to ask:
How does this activity create value?
What outcomes matter to users?
How can we make this experience better while reducing the burden on IT staff?
The Modern Approach: User Experience Over Technical Correctness
ITIL 4’s emphasis on user experience and value streams transforms how we should think about password resets. The framework maintains the technical distinction that password resets are service requests, but it encourages organizations to think more broadly about the entire experience.
Modern Best Practices
1. Business Impact Drives Priority
Principle: Implement appropriate service level agreements for both incidents and service requests based on business impact.
A user locked out of a critical system needs help quickly, regardless of classification
The classification shouldn’t determine the urgency; the business impact should
SLAs designed around outcomes: How quickly does Sarah need to be back at work?
2. Automation and Self-Service
Principle: Users shouldn’t need to call the service desk at all for simple password issues.
Benefits:
Users get instant assistance through automated systems
Identity verification and password reset happens instantly
IT staff freed for more complex work
Creates value by reducing wait times
3. Practices Over Processes
Principle: Think in terms of integrated practices rather than rigid processes.
Integration Points:
Service Request Management integrates with:
Incident Management
Problem Management
Change Management
Example Scenario: When password reset volumes spike →
Trigger Problem Management to investigate root causes
Questions to ask:
Is poor password policy forcing frequent resets?
Do users need better training?
Is password complexity causing more harm than good?
The Four Dimensions: A Holistic View
ITIL 4 introduces four dimensions of service management that apply perfectly to our password reset scenario. Organizations need to consider all four dimensions to deliver effective services.
1. Organizations and People
Focus: Human behavior and technical systems
Considerations:
Password resets involve both technical systems and human behavior
Corporate culture affects how users approach security
Staff capacity determines fulfillment speed
Organizations with poor security awareness training see higher reset volumes
2. Information and Technology
Focus: Technical capabilities
Includes:
Identity management systems
Self-service portals
Multi-factor authentication
Knowledge bases to help users prevent lockouts
3. Partners and Suppliers
Focus: External relationships
Considerations:
Identity-as-a-service providers
Single sign-on solutions from vendors
Partnership affect on password reset handling
Service levels achievable through external providers
4. Value Streams and Processes
Focus: Integrated organizational workflows
Flow Example: Password reset request → Service desk → Identity management teams → Security groups
Requirement: Coordination across teams to deliver value efficiently
Practical Implementation: Getting It Right
So how should modern organizations handle password resets in practice? The answer combines technical correctness with pragmatic flexibility.
Step 1: Classify Correctly
Rule: Classify standard password resets as service requests
Rationale:
✓ Technically correct according to ITIL
✓ Provides accurate metrics about infrastructure stability
✓ Shows true service demand
When user forgets password or gets locked out due to typing errors → Nothing is broken in IT systems
Security mechanisms working exactly as designed
Exception: Investigate patterns that might indicate incidents
Multiple users suddenly need password resets
Password reset system itself fails
Use monitoring and alerting to detect patterns automatically
Step 2: Implement Self-Service
Action: Deploy password reset capabilities with appropriate security controls
Benefits:
✓ Immediate value for users
✓ Reduced service desk workload
✓ Aligns with ITIL 4’s emphasis on automation
✓ Leverages modern identity management technologies
Security: Multi-factor verification allows users to reset passwords without human intervention
Step 3: Design Impact-Based SLAs
Principle: Service level agreements should reflect business impact rather than technical classification
Key Questions:
How quickly does Sarah from accounting need to be back at work?
What’s the business impact of this lockout?
Does the application criticality matter more than the ticket type?
Design Approach: Create SLAs around outcomes, not classifications
Step 4: Use Service Catalogs Effectively
Action: Clear, user-friendly service portals where people can find what they need quickly
ITIL 4 Encouragement:
Simple interfaces
Clear options like:
“Something is Broken” (Incident)
“I Need Something” (Service Request)
Helps users self-classify correctly
Improves data quality and routing efficiency
The Bigger Picture: Why This Matters
The password reset debate illustrates something fundamental about ITIL’s evolution from Version 2 to Version 4.
ITIL’s Journey
Era
Focus
What Organizations Needed
ITIL 2
Structure and process definition
Clear rules when IT service management was immature
ITIL 3
Lifecycle thinking
Integration across service stages
ITIL 4
Flexible value creation
Guidance that integrates with modern practices
The Paradigm Shift
From: Rigid process adherence To: Flexible value creation
Why: The world has changed
Modern organizations use cloud services
Agile methodologies are standard
DevOps practices are widespread
Need guidance that integrates, not competes
The Real Questions
The password reset question becomes less about finding the single “correct” answer and more about understanding principles:
Why does the distinction matter?
What value does proper classification create?
How can we improve the user experience while maintaining meaningful metrics?
Are we delivering value to our users while maintaining visibility into IT operations?
Are our metrics helping us make good decisions about where to invest?
Missing the Forest for the Trees
Organizations caught up in debates about technical classification often overlook what truly matters:
Delivering value to users
Maintaining visibility into IT operations
Using metrics to make informed investment decisions
Conclusion: Embracing the Evolution
After decades of debate, the answer to whether password resets are incidents or service requests remains nuanced.
The Technical Answer
In most cases: Service Requests
Because:
Nothing is broken in IT infrastructure
Security system working as designed
Users need assistance with routine activity
Follows standard procedures
Exceptions exist:
Technical failures cause access problems
Wise organizations remain alert to these patterns
Why classification matters:
Affects metrics that inform critical business decisions
Influences IT investment priorities
The ITIL 4 Perspective
Getting the technical classification right is just the beginning. The framework encourages us to:
✓ Think about value creation
✓ Focus on user experience
✓ Prioritize outcomes over process compliance
✓ Automate routine requests
✓ Design services around user needs
✓ Integrate IT service management with modern practices
What Really Matters
When Sarah from accounting calls about being locked out, the most important thing isn’t whether your service desk agent logs it in the incident or request queue.
What matters:
She gets back to work quickly
Your metrics accurately reflect your IT operations
Your organization learns from these interactions to improve services over time
The Real Evolution
From ITIL 2 to ITIL 4:
Rigid process adherence → Flexible value creation
Technical correctness → User-centered service design
Debating classifications → Delivering outcomes that matter
The Ultimate Lesson
The password reset question, in the end, teaches us that ITIL is a framework to guide thinking, not a rulebook to follow blindly. And that might be the most important lesson of all.
