Latest Articles

80% of Problems Come from 20% of Causes — Pareto Analysis Identifies What Matters Most The Pareto Principle The Pareto Principle (the 80/20 rule) suggests that roughly 80% of effects come from 20% of causes. Applied to problem management, this means that a small number of root causes are responsible for the majority of incidents. What Is Pareto Analysis? Pareto Analysis is a statistical technique used to identify the most significant causes contributing to the problem. By focusing on the "vital few" rather than the "trivial many," teams can maximize the impact of their problem management efforts. How to Perform Pareto Analysis Step 1: Collect Data Gather data on incident causes over a defined period: Track incident categories Record root causes Count frequency of each cause Step 2: Categorize Causes Group incidents by cause or category: What are the most common categories? What are the most frequent root causes? What systems have the most incidents? Step 3: Sort and Calculate Sort causes from most frequent to least frequent Calculate the percentage of total incidents for each cause Calculate the cumulative percentage Step 4: Create a Pareto Chart Bar chart showing frequency of each cause (descending) Line chart showing cumulative percentage Step 5: Identify the "Vital Few" Identify causes that account for 80% of incidents Focus problem management efforts on these causes Example Pareto Analysis Data from a service desk: Cause Count % of Total Cumulative % Password resets 450 30% 30% Application crashes 300 20% 50% Network issues 250 17% 67% Email problems 180 12% 79% Printer issues 120 8% 87% Other 200 13% 100% The "vital few" : Password resets, application crashes, network issues, and email problems account for 79% of incidents. Action: Focus problem management on these four areas. Benefits of Pareto Analysis Benefit Impact Focus Teams concentrate on what matters most Resource allocation Invest where returns are highest Quick wins Fixing top causes has immediate impact Strategic planning Data-driven decision making When to Use Pareto Analysis Scenario Use Case Many causes When there are too many potential causes to address all at once Data available When you have data on cause frequency Resource constraints When you need to prioritize Quick results When you need to show impact quickly Combining Pareto with Other Techniques Pareto identifies which causes to investigate (top 20%) 5 Whys investigates each of the top causes Ishikawa diagrams show the relationships Conclusion Pareto Analysis helps organizations focus on the "vital few" causes that generate the majority of incidents. By targeting these causes, problem management teams can have the greatest impact with limited resources. Action Items for Your Organization Collect data on incident causes over a defined period Perform Pareto Analysis on the data Identify the "vital few" causes Focus problem management resources on these causes Track the reduction in incidents from top causes

Incident management is a process to handle the issues reported by users, in the most efficient manner. Although most of the large organizations have already placed one or other mechanism to deal with such incident processes, however, it is important for the organizations to evaluate the entire incident management lifecycle and process to ensure that the right processes are in place to handle issues in the most efficient and faster manner. As technology is moving faster than ever before, similarly ITSM products are adding up new features and functionalities to help organizations to deal with incidents. Below are the key parameters, against which the Incident management process of any organization can be evaluated. Supported Channels for Incident Creation Reporting the incident in a faster manner helps to reduce the TAT for the incident, therefore it is important to look into the various channels which can be used to report the incident in real time. It enables users to choose the right way to log the incident. The most common channels are Email to ticket conversion, Using the user portal, SSO with other platforms such as O365, GSuite etc., Ticket logging by Chat-Bot, and Manual ticket creation by technician. Ability to Capture Important Information While logging the incident by the user, it has been observed in the past that relevant information has not been provided by the user which could be useful for support teams to understand the issue in detail. Hence ITSM tool should have provision to capture all the relevant information such as appropriate category, sub-category, asset details, warranty details etc... With the help of ITSM tools, organizations can create custom templates for the tickets which can be used by the users and fill in all the relevant information automatically at the time of ticket creation. Auto-Categorization & Auto-Assign Putting the incident into the right bucket is very important to avoid unnecessary delays in resolving the incident. If the user is using the portal to log the incident, templates can be used to raise the incident but, in the email,-to-ticket scenario, it is a tedious task to manually assign the categories/sub-categories. ITSM tools can help in doing the auto-categorization by analyzing the ticket contents using machine learning capability. ITSM should be able to assign the incident automatically to concerned support teams after categorization. Closer Look at Remaining or Elapsed Time While every incident is bound to be closed within SLA timelines, it is important to keep track of timelines during the incident lifecycle. If timelines are not being tracked, there are chances of breach of SLA timelines. ITSM tools now provide the capability to support teams to look into the timelines in terms of how much time is remaining as per SLA and severity of tickets and if ticket timelines are breached what is the overdue time. With the latest ITSM tools it is now possible to define the timelines at the granular level which includes office timings based on different locations, based on different holiday calendars etc. Auto-Escalations & Notifications While timelines can be tracked, the ITSM tool should also provide the capability to automatically escalate the incident ticket to higher authorities based on the time elapsed on ticket. ITSM tool should provide the notifications at various stages such as escalation notification, ticket status change notification, ticket closure notification etc. Diagnosis & Resolution While an incident ticket captures the symptoms, issue details etc. at the time of ticket creation, the ITSM tool should also provide the capability to support teams to capture more details such as how the diagnosis has been performed, which kind of solutions have been tried or applied or what was the root cause analysis for a particular incident. This information helps other support team members to look into similar resolved tickets in future for faster resolution of incidents. Self-Healing Managing the incident lifecycle is important but IT leaders should also look into various ways to reduce the no. of incidents in the organization. Self-heal bundled with automation scripts can help users to fix their issues automatically or using the right IT Asset Management tool, issues can be automatically detected and based on predefined conditions, and those issues can be fixed automatically. Organizations can use custom scripts based on the type of incidents in their organization. Self-heal functionality can reduce the no. of incident tickets up to 30% and helps to reduce the workload at the support desk. Ability to mark FCR, Impacted CIs, Major Incident etc. Apart from the basic classification based on category, severity etc. ITSM tool should also be able to mark the ticket for FCR (First Call Resolution), Major Incident or Impacted Cis/Business Services.  This helps IT leaders to look into actionable intelligent and plan for continuous improvement of IT Support Services.  

Headline: "Change Is Always-On" — The New Reality of Organizational Transformation The Always-On Reality "'Change is always-on'... I'm going to get that printed on a t-shirt," remarks the CIPD's Change Management Lead Claire Hodson . Organizations no longer go through change in isolated waves. They operate in a state of constant evolution, where shifts in technology, skills, and expectations happen at the same time . What Always-On Change Means Being "always-on" means embedding change capabilities into the DNA of the organization. This approach to transformation is not about preparing for change, it is about living in it every day . Change does not happen in neat phases. It is often nonlinear, unpredictable, and requires constant adaptation. Research reveals that 64 percent of respondents experience changes in the flow of everyday work. While some organizations are adapting to an always-on culture, most are not fully equipped to effectively support and alleviate the impact of change as it happens in daily operations . Avoiding Change Fatigue Change fatigue occurs when employees are overwhelmed by constant change. Organizations must build up organizational "change muscles" that enable individuals and teams to adapt continuously . Strategies: Normalize constant evolution Provide curated, personalized support Foster resilience through learning and adaptation Use AI to sense behaviors and tailor experiences What Always-On Change Looks Like Organizations that embrace always-on change: Harness AI: Use AI to sense people's behaviors and tailor experiences at scale  Provide coaching: Equip managers to help workers navigate overlapping initiatives  Build resilience: Embed change capabilities into the fabric of operations  Make it a living system: Change becomes a responsive, adaptive, experiential capability  The Electric Car Analogy Think of always-on change as something like an electric car that constantly updates its software after purchase: there are new features, improved performance, and small refinements that never stop. Similarly, change should be embedded in the product lifecycle, not treated as a one-off event . Conclusion Change is not slowing down. Organizations that build always-on change capabilities will be better positioned to adapt with purpose and resilience instead of reacting too late . Rather than optimizing for a single plan, always-on change prepares people for multiple possible futures. Action Items for Your Organization Assess your organization's change readiness for constant change Build organizational "change muscles" Use AI to sense and respond to change in real time Provide coaching and support for employees Normalize constant evolution

Headline: Why ITIL Renamed Change Management to Change Enablement — And What It Means for You The Change That Changed Change Management With the release of ITIL 4 in November 2018, Change Management became Change Enablement . The reason? Change Management never truly "managed" or "controlled" anything—it authorized changes. The purpose of the practice has not changed, but the philosophy has . The ITIL 4 Definition The purpose of Change Enablement is "to maximize the number of successful service and product changes by ensuring that risks have been properly assessed, authorizing changes to proceed, and managing the change schedule" . Key Differences Dimension ITIL v3 Change Management ITIL 4 Change Enablement Focus Controlling changes Enabling changes efficiently Decision-making Centralized CAB Decentralized Change Authorities Pace Risk-averse, often causing delays Risk-based, balancing speed and control Automation Minimal High, with AI-driven risk assessment DevOps Integration Limited Embraces DevOps practices Why the Shift? DevOps and Agile: ITIL 3 was published in 2007 and revised in 2011 when DevOps didn't play such an important role in IT service management. ITIL 4 reflects the changing nature of IT operations . Speed: Modern IT organizations now recognize the value of faster iterative feedback loops. These reduce costs and lead to smaller change project implementations before cross-organization deployments . Distributed Decision-Making: Instead of encouraging companies to appoint a single Change Advisory Board (CAB), ITIL 4 promotes designating change-focused people across various teams . What This Means for Your Organization From Gatekeeper to Enabler The shift is philosophical. ITIL v3 Change Management was about control—controlling what changes, when, and by whom. ITIL 4 Change Enablement is about enabling successful change by balancing risk and speed. More Automation ITIL 4 encourages using tools and technology to track workflows, backlogs, implementation, deployments, feedback loops, and collaborative processes . Faster, Safer Changes "Everything should be as simple as possible, but not simpler." While ITIL 4 allows for faster changes, it still requires thorough risk assessment—just in a more flexible, context-appropriate way. Conclusion ITIL 4's Change Enablement isn't just a name change—it represents a fundamental shift in philosophy. From gatekeeper to enabler, from centralized to distributed, from slow to fast. Organizations that embrace this shift will be better positioned for modern IT operations. Action Items for Your Organization Review your change management philosophy—gatekeeper or enabler? Assess your current decision-making model Identify opportunities to delegate change authority Implement automation for standard changes Embrace DevOps practices in change management

Only 2% Report Firm-Wide Cyber Resilience — The Governance Gap That Keeps CISOs Up at Night The Resilience Gap PwC's Global Digital Trust Insights 2025 highlights a stark reality: while 77% of organizations plan to increase cyber budgets, only 2% report firm-wide cyber resilience . This gap points to missing governance structures, unclear decision rights, and insufficient board-level accountability . What Is the Governance Gap? The governance gap is the distance between what compliance documentation says and what the organization actually is . It manifests as: Fragmented ownership models Siloed data Legacy GRC tools Delayed risk insights Incomplete risk visibility Disconnected operational reality Why the Governance Gap Exists Assumptions That No Longer Hold The systems, processes, and assumptions that got you here were built for a world that moves more slowly than the one you operate in now . Your GRC stack was built for a world that no longer exists: The pace of change is faster: Engineering deploys changes hourly; your quarterly access review captures a snapshot that has already changed by the time it's complete . New vendors appear daily: A new vendor gets embedded in production before procurement is notified . AI changes everything: A vendor you approved for one purpose now uses AI in ways you never signed off on . The Assurance Gap The result is an assurance gap: the distance between what your compliance documentation says and what your organization actually is . Your team fills that gap with judgment and extra hours, but that is not sustainable when the rate of change keeps accelerating. The GRC Operating Model Problem One head of GRC described: running audits, answering security questionnaires, managing third-party risk, maintaining the trust center, and setting the certification strategy—all on their own. Their tools automate the repeatable parts, but the judgment calls, the context shifts, the things that happen between scheduled reviews—those fall entirely on one person . What Mature Organizations Are Doing Connected GRC Platforms CISOs are adopting connected GRC platforms that provide holistic visibility across risk domains. This connected approach is essential for understanding how risks cascade across the organization and for coordinating response efforts across security, risk, compliance, and the business . Integrated Risk Management Cyber risk no longer exists in isolation. It is deeply interconnected with third-party risk, operational risk, regulatory risk, and enterprise resilience. Connected GRC enables better prioritization, faster response, and stronger alignment between cyber risk management and business objectives . The Trust Management Lesson The trust landscape in 2026 is demanding more from GRC teams than the current operating model was designed to deliver . Recognizing that the model needs to evolve is the most important lesson of the year, and it is the first step toward building something that can actually keep pace. Action Items for Your Organization Assess your current GRC operating model Identify gaps between documentation and reality Build governance structures with clear accountability Adopt connected GRC platforms Define clear decision rights Measure and close the assurance gap  

VRM Is Hard — Here's Why and How to Succeed The VRM Challenge Landscape Developing and maintaining a vendor risk management practice is no easy task . Understanding the challenges is the first step to overcoming them. Challenge 1: Getting Stakeholder Buy-In The Problem: Convincing executives and stakeholders of VRM's importance is difficult, especially without visible ROI . Why It Happens: VRM's benefits (preventing incidents) are harder to quantify than its costs. Many executives see VRM as a cost center rather than a value driver. How to Overcome: Translate vendor risk into business outcomes (dollars, downtime, safety)—not colored heatmaps  Connect VRM to loss exposure, mitigation cost, and operational impact  Use Cyber Risk Quantification (CRQ) to translate vendor exposure into concrete financial terms  Challenge 2: Identifying All Vendors The Problem: Some large organizations don't have a centralized location to manage all vendors. Understanding what's in use and who is using it on a day-to-day basis is a complex task . Why It Happens: Vendors are onboarded by different departments, through different processes, without a central register. How to Overcome: Automate vendor discovery Implement a centralized vendor inventory Use risk-based tiering to prioritize and contextualize risk  Challenge 3: The "Long Tail" The Problem: Teams pour energy into the obvious "critical" vendors while the broader ecosystem remains lightly assessed, inconsistently monitored, and operationally under-controlled . It's that long tail that will eat you much more quickly . Why It Happens: Resource constraints force prioritization of obvious risks. The long tail is invisible until it's too late. How to Overcome: Implement a scalable triage and monitoring approach  Use AI to automate evidence review  Focus on the "long tail" that can hurt you faster than critical vendors Challenge 4: Manual, Inefficient Processes The Problem: Manual input on spreadsheets is time-consuming and prone to human error . 76% of GRC professionals still spend 30% or more of their working hours on repetitive, manual administrative tasks. Why It Happens: Legacy approaches rely on manual evidence collection and assessment. How to Overcome: Leverage technology and automation  Adopt specialized TPRM software  Use AI to automate evidence review  Challenge 5: Uncooperative Vendors The Problem: Some vendors do not provide complete or timely information, adding to assessment difficulties . Large vendors may refuse to upload documentation, share reports, or play nicely with your third-party risk management tools . Why It Happens: Vendors have limited resources or see VRM as a burden rather than a partnership. How to Overcome: Treat non-cooperation as a risk signal  Exercise leverage where you can  Use alternative data (threat intel, outside-in scans, etc.) when you can't  Negotiate stronger contractual clauses covering data access and transparency  Challenge 6: Keeping Up with Regulations The Problem: Changing laws and standards—and remaining current with them—adds further complexity . The evolving threat landscape requires continuous updating of assessment criteria and controls . Why It Happens: Regulations are increasing year-on-year, and enforcement is tougher. How to Overcome: Use horizon scanning to quickly identify and mitigate emerging risks  Establish dynamic frameworks that adapt to regulatory changes  Provide continuous education and training  Challenge 7: Data Quality and Integration The Problem: Non-integrated platforms across departments (IT, procurement, legal) escalate operational inefficiency . Opaque visibility into sub-tier vendor activities is harder to monitor without adequate technological interventions . Why It Happens: Different departments use different tools and processes. How to Overcome: Centralize incoming information to see the big picture  Move from reactive to proactive risk management  Adopt a hub and spoke governance model  The Bottom Line VRM is hard, but the alternative—unmanaged vendor risk—is harder. Organizations that acknowledge these challenges and build systematic approaches to overcome them will be better positioned to protect their business. Action Items for Your Organization Identify your top VRM challenges Develop strategies to address each challenge Leverage technology and automation Build cross-functional collaboration Provide continuous education and training