Latest Articles

Are You Doing GRC or Just Going Through the Motions? — The GRC Maturity Model The Maturity Model GRC maturity describes how advanced your risk management practice is. Maturity Levels Level 1: Initial/Ad-Hoc Characteristics: No formal risk management Ad-hoc processes Inconsistent execution No ownership Reactive Signs you're at Level 1: Risks are managed informally No risk register No formal assessments Level 2: Repeatable Characteristics: Basic processes exist Some documentation Inconsistent execution Emerging ownership Signs you're at Level 2: Risk register exists but may be incomplete Some formal assessments Some ownership Level 3: Defined Characteristics: Standardized processes Documented workflows Clear ownership Regular assessments Basic reporting Signs you're at Level 3: Risk register is maintained Formal assessments on schedule Clear risk owners Reporting to management Level 4: Managed Characteristics: Process performance measured Proactive improvement Risk-based decision-making Integration with other processes Signs you're at Level 4: KRIs are tracked Continuous monitoring Integration with incident management Board reporting Level 5: Optimizing Characteristics: Continuous improvement AI-driven risk management Predictive analytics Enterprise-wide integration Signs you're at Level 5: AI for risk identification and assessment Predictive risk analytics Fully integrated GRC Autonomous risk management Maturity Assessment Questions Area Question Risk Identification Do you have a formal process? Risk Assessment Do you assess risks regularly? Risk Treatment Do you have treatment plans? Risk Monitoring Do you monitor risks continuously? Ownership Are risks and controls owned? Reporting Do you report to stakeholders? Integration Is GRC integrated with other functions? Building a Roadmap Level 1 → Level 2: Create risk register Define basic process Assign ownership Level 2 → Level 3: Standardize processes Establish regular assessments Define treatment plans Level 3 → Level 4: Implement KRIs Establish continuous monitoring Integrate with other functions Level 4 → Level 5: Implement AI and automation Enable predictive analytics Achieve continuous improvement Conclusion GRC maturity is a journey. Organizations that assess their maturity and build a roadmap for improvement will achieve better risk outcomes and demonstrate the value of GRC. Action Items for Your Organization Assess your current GRC maturity Identify gaps Build a roadmap to the next level Measure progress Celebrate improvements

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

Stop Reacting to Requests — Use Trend Analysis to Identify Problems Before They Explode The Power of Trend Analysis Trend analysis enables teams to clearly identify which types of service requests and inquiries are trending, enabling proactive resolution of broader issues . What to Look For Trend What It Means Action Spike in access requests New hires, role changes, or security issues Review onboarding process Increase in software requests New tools being adopted Review license management Rise in password resets Policy issues or system problems Review authentication Hardware requests increasing Growth or equipment lifecycle Review procurement How to Do Trend Analysis 1. Collect Data Gather request data over time — type, volume, patterns. 2. Identify Patterns Look for patterns: time of year, day of week, related events. 3. Investigate Causes When you see a pattern, investigate why it's happening. 4. Take Proactive Action Fix the root cause, not just the individual requests. 5. Monitor Impact Track whether your proactive action reduced the trend. Example: Trend Analysis in Action Observation: Password reset requests spike every Monday morning. Analysis: Employees forget passwords over the weekend and need resets Monday. Proactive Action: Implement MFA or passwordless authentication. Result: Password reset requests drop by 50%. Tools for Trend Analysis Tool Type Capability ESM platforms Built-in analytics and dashboards BI tools Advanced visualization and analysis AI/ML Automated pattern detection Conclusion Trend analysis transforms service request management from reactive to proactive. Instead of handling the same problems repeatedly, organizations can identify and fix root causes — reducing volume and improving service. Action Items for Your Organization Review your data — what patterns do you see? Investigate root causes of trends Take proactive action Monitor the impact Share findings with stakeholders