Latest Articles

Why Fragmentation Is Killing Your Service Request Management — And How to Fix It The Fragmentation Problem Collecting and managing all service requests in one place is essential to avoid duplicate work and provide employees with a central location for help . Yet many organizations still have separate processes, tools, and portals for different departments. Why Centralization Matters The Employee Perspective Employees don't want to remember which system handles which request. They want one place to go for everything . The Operational Perspective Fragmentation creates duplicate work, inconsistent processes, and poor visibility. Centralization gives a bird's-eye view of all requests — including status, timeline, and owner — and enables better tracking and reporting . Steps to Centralize Request Management 1. Map the Current Landscape Identify all current request entry points — portals, email, chat, phone, walk-ins. Document what types of requests go where. 2. Define a Unified Entry Point Create a single portal for all service requests. This doesn't mean every request is handled the same way — it means every request starts in the same place . 3. Build Cross-Department Workflows Requests that span departments should flow automatically between teams . Users shouldn't need to know which department handles which request. 4. Unify Reporting With all requests in one system, you can see the full picture — volume trends, resolution times, satisfaction scores across all departments. 5. Communicate the Change Tell employees: "All service requests now start here." Make it clear and simple. Benefits of Centralization Benefit Impact One place for employees No more guessing which system to use Complete visibility See all requests in one place Consistent experience Same interface across departments Better tracking Request status visible to all Clearer reporting Complete data for analysis Conclusion Centralization is the foundation of effective service request management. Without it, you have fragmented processes, frustrated employees, and poor visibility. With it, you have a single, consistent, trackable system for all service needs. Action Items for Your Organization Map all current request entry points Identify duplicate and fragmented processes Define a single portal for all service requests Build cross-department workflows Communicate the change to employees Measure the impact on efficiency and satisfaction  

When Your AI Agents Need to Consult the Knowledge Base — RAG for Cybersecurity Incident Response The Knowledge Problem in Incident Response Incident responders need knowledge. They need to know: What's happened before in similar incidents What worked and what didn't What the current system state is What the dependencies are But knowledge is often: Spread across multiple systems Outdated Inconsistent Hard to find Retrieval-Augmented Generation (RAG) addresses this problem by enabling AI agents to consult external knowledge bases during incident response. What Is RAG? RAG is a technique that enhances AI capabilities by retrieving relevant information from external knowledge bases and incorporating it into AI generation. How RAG Works User query: AI receives a query about an incident Retrieval: AI retrieves relevant information from knowledge bases Augmentation: AI incorporates retrieved information into its response Generation: AI generates a response incorporating both its training and the retrieved information RAG for Incident Response AutoBnB-RAG AutoBnB-RAG extends multi-agent incident response simulations with RAG, enabling agents to issue retrieval queries and incorporate external evidence during collaborative investigations. RAG Data Sources Source Example Use Technical documentation (RAG-Wiki) Incident resolution steps, system architecture, API documentation Narrative-style incident reports (RAG-News) Past incident summaries, lessons learned, postmortems Runbooks Step-by-step incident response procedures Knowledge articles Known issues and resolutions The Benefits of RAG in Incident Response Benefit Impact Access to current knowledge Always up-to-date information Consistent responses Same knowledge applied consistently Faster investigation Knowledge is retrieved, not searched for manually Better decisions Evidence-based decisions Knowledge reuse Past lessons applied to present incidents RAG Implementation for Incident Response 1. Build Knowledge Sources Source Content Format Runbooks Step-by-step procedures Structured documents Knowledge articles Known issues and resolutions Article format Postmortems Past incident learnings Documented reports Documentation System architecture, dependencies Technical docs CMDB Configuration items and relationships Structured data 2. Implement Retrieval Options for retrieval implementation: Vector databases (e.g., Pinecone, Weaviate) Search engines (e.g., Elasticsearch) Hybrid (both) 3. Implement Augmentation The AI is augmented to: Issue retrieval queries Incorporate retrieval results into responses Cite sources (for transparency) 4. Validate Knowledge Knowledge validation is essential: Regular reviews of knowledge sources Feedback loops (did this knowledge help?) Knowledge lifecycle management RAG vs. Training Dimension RAG Training Knowledge updates Instant Requires retraining Knowledge freshness Always current Can become stale Knowledge source Retrieval from external sources Embedded in model weights Transparency Can cite sources Black box Cost Lower (no retraining) Higher (retraining costs) Conclusion: RAG Supercharges Incident Response RAG enables AI agents to access current, relevant knowledge during incident response. The result is faster, more consistent, and more accurate incident resolution. Incident response is increasingly collaborative—between humans and AI, between AI agents. RAG makes this collaboration work better. Action Items for Your Organization Build knowledge sources: Ensure runbooks, knowledge articles, and postmortems are current and accessible Implement RAG: Choose a RAG implementation and integrate with incident response workflows Validate knowledge: Establish processes for knowledge quality and currency Use RAG for incident response: Enable AI agents to retrieve knowledge during incident response  

Static Assessments Are Dead — Continuous Monitoring Is the Only Way Forward The Death of Static Assessments Spreadsheet-based, annual assessments are dead. They are too slow and too resource-intensive to manage an environment where a vendor's risk posture can change daily . Point-in-time assessments fail because: Vendors change their security posture continuously New threats emerge daily Compliance requirements evolve Fourth-party risks emerge unexpectedly What Continuous Monitoring Looks Like Real-time data collection: Systems continuously collect and analyze data from multiple sources—security ratings, threat intelligence, financial data, and adverse news . Automated alerts: When risk indicators change, alerts are triggered immediately . Ongoing compliance verification: Vendor compliance is verified continuously, not just during periodic assessments. The result: Organizations can move from reactive to proactive risk management . The Business Case for Continuous Monitoring Benefit Impact Immediate gap detection Risks are identified as they emerge Faster response Automated alerts enable rapid action Better visibility Real-time view of vendor risk posture Reduced manual effort Automation eliminates manual monitoring Proactive risk management Issues are addressed before they become incidents AI-Enabled Continuous Monitoring AI-driven monitoring identifies anomalies in third-party behaviors and compliance infractions instantly using AI models trained on data patterns . Key capabilities: Real-time visibility into vendor security posture Automated vendor screening and rescreening  Integration of external data feeds for financials and negative news  Dynamic risk scoring that adapts to changing conditions  Beyond Third-Party: Fourth-Party Monitoring Continuous monitoring should extend to fourth parties and beyond . A vendor's subcontractors may introduce significant vulnerabilities that affect your organization. The challenge: Sub-tier vendor activities, known as fourth-party or nth-party risks, are harder to monitor without adequate technological interventions . The solution: Use technology to extend visibility across the entire supply chain. The Regulatory Driver Regulatory bodies increasingly expect continuous monitoring. Frameworks like the Financial Conduct Authority (FCA) and Monetary Authority of Singapore (MAS) emphasise monitoring third-party interactions . DORA, the EU's Digital Operational Resilience Act, requires financial entities to maintain structured ICT incident records and reporting discipline—raising the importance of continuous monitoring of third parties. Conclusion Continuous monitoring is the new enterprise standard for VRM. Organizations that move beyond static assessments to continuous, risk-quantified monitoring will tackle the dynamic nature of their environment . Action Items for Your Organization Move from annual to continuous vendor assessments Implement automated monitoring tools Set up real-time alerts for risk changes Extend monitoring to fourth parties Integrate external data feeds for comprehensive visibility  

 Problem Management Doesn't Operate in a Silo — How Integration Creates a Resilient IT Ecosystem The Integration Imperative Problem management should not operate in isolation. Integrate it with incident management, change management, and knowledge management to ensure a holistic approach to IT service management . Integration with Incident Management The Problem-Incident Relationship Although Incident Management and Problem Management are separate processes, they are closely related and will typically use the same tools, and may use similar categorization, impact and priority coding systems. This will ensure effective and consistent communication when dealing with related incidents and problems . Key integration points: Incidents trigger problems (recurring incidents, major incidents) Problems have linked incidents Known errors help resolve incidents faster Incident trends inform problem priorities Integration with Change Management The Problem-Change Relationship Within problem management, the Request for Change (RFC) ticket will be the output for fixing errors where cause is known . Key integration points: Problems generate change requests to implement fixes Change management tracks implementation of fixes Problems can be updated with change status Changes can be linked to problems ServiceNow integration: Enables the creation of change requests directly from the problem record, ensuring a seamless transition from problem management to change management. Integration with Knowledge Management The Problem-Knowledge Relationship Problem Management will also maintain information about the appropriate workarounds and resolutions to problems, so that the number and impact of incidents can be reduced over time. In this respect, Problem Management has a strong interface with Knowledge Management, and tools such as the Known Errors Database (KEDB) will be used to document workarounds and root cause . Key integration points: Known errors are documented in the knowledge base Workarounds are captured as knowledge articles Problem insights inform knowledge creation Knowledge helps prevent incident recurrence Integration Benefits Benefit Description Faster resolution Known errors help incidents resolve faster Better data quality Consistent data across processes Complete visibility See the full picture across processes Knowledge sharing Lessons learned are captured and shared Risk reduction Changes are evaluated before implementation The Integration Ecosystem text Incident Management → Problem Management        ↓                      ↓ Problem Management → Change Management        ↓                      ↓ Problem Management → Knowledge Management        ↓                      ↓ Knowledge Management → Incident Management How to Implement Integration 1. Use a Unified Platform The same ITSM platform for all processes Consistent data models Built-in integrations 2. Define Integration Points What data is shared? When do handoffs occur? Who is responsible? 3. Configure Integrations Link incident and problem records Create change requests from problems Publish known errors to the knowledge base 4. Train Teams How the processes work together When to transition between processes How to use integrated tools Conclusion Problem management is most effective when integrated with incident, change, and knowledge management. This integration creates a resilient ITSM ecosystem where learning is captured, fixes are implemented, and incidents are prevented.

Service Requests Contain Sensitive Data — Here's How to Keep It Secure The Security Challenge Service requests often contain sensitive data: identity information, access details, HR records, and workflow evidence. The Cloud Security Alliance reports that 80% of enterprises have experienced unintended AI agent actions, and 39% have encountered agents that accessed unauthorized systems. Regulatory Context The EU Digital Operational Resilience Act (DORA) became fully applicable on January 17, 2025, requiring financial entities to maintain structured ICT incident records and reporting discipline — raising the importance of secure logging and traceable workflows . Security Risks in Service Requests Risk Example Data exposure Request contains sensitive personal or business information Unauthorized access AI agent accesses systems or data without proper authorization Shadow AI Unauthorized AI tools used without governance Weak AI identities Only 22% of organizations have proper identities tied to their AI agents Permission creep AI agents with excessive permissions Best Practices for Secure Service Request Management 1. Implement Identity and Access Management for AI Capability Purpose Unique AI identities Accountability for AI actions Least privilege Only grant necessary permissions Access reviews Regular permission validation Lifecycle management Provision and revoke access 2. Monitor AI Behavior Capability Purpose Real-time monitoring Detect AI incidents Anomaly detection Identify unusual behavior Audit logging Investigate incidents 3. Protect Sensitive Data Capability Purpose Data classification Understand what data is in requests Access controls Only authorized users can access sensitive data Data minimization Only collect what's needed 4. Build AI Governance Capability Purpose AI risk assessment Understand AI risks AI compliance monitoring Ensure regulatory compliance AI incident reporting Report AI incidents Conclusion Security and privacy are essential considerations in service request management. Organizations must implement governance, access controls, and monitoring to protect sensitive data and ensure compliance. Action Items for Your Organization Audit current AI agent identities and permissions Implement least privilege for all AI agents Monitor AI behavior in real-time Protect sensitive data in service requests Build AI governance frameworks Prepare for regulatory compliance (DORA, GDPR, EU AI Act)  

Headline: Controls Fail — The Question Is Whether You're Managing the Failure Effectively The Exception Reality Controls fail. The question isn't whether they fail, but whether you're managing exceptions effectively. What is a control exception? A control exception occurs when a control is not operating as designed or is not achieving its objective. The Exception Lifecycle 1. Identification Exceptions can be identified through: Control monitoring Control testing Internal audit External audit Incident response Employee reports 2. Assessment When an exception is identified, assess: Question Consideration What is the impact? Business, regulatory, operational What is the root cause? Why did the control fail? What is the risk? What is the residual risk? What are the compensating controls? Are there other controls that mitigate the risk? 3. Remediation Develop and implement a remediation plan: Identify the root cause Develop corrective actions Assign ownership Implement remediation Verify the fix Update controls 4. Approval Exceptions may require formal approval: Exception Type Approval Required De minimis Minimal risk, no approval needed Low impact Control owner approval Medium impact Business owner approval High impact Executive approval, board reporting 5. Tracking Track exceptions through resolution: Exception ID Control affected Impact assessment Root cause Remediation plan Owner Status Target date Approval date Compensating Controls When a control fails, compensating controls may mitigate the risk: Primary Control Failed Compensating Control Automated access review not run Manual review by manager Firewall rule misconfigured IPS/IDS alerting MFA not enforced Enhanced monitoring Patch not applied Additional monitoring The Exception Governance Framework Key elements: Exception policy: Defines when exceptions can be accepted Exception process: Defines how exceptions are managed Exception authority: Defines who can approve exceptions Exception reporting: Defines how exceptions are reported Key governance questions: Are exceptions documented? Are they approved by the right authority? Are they reviewed regularly? Are they tracked to resolution? Conclusion Controls fail—the question is whether you're managing exceptions effectively. Organizations with a structured exception management process will identify, assess, and remediate control failures quickly, reducing risk exposure. Action Items for Your Organization Establish an exception management policy Define the exception process Assign exception authority Implement exception tracking Review exceptions regularly Track exceptions to resolution