Latest Articles

The Seven Stages of Problem Management — A Complete Guide to the Process Overview of the Problem Management Lifecycle The Problem Management lifecycle ensures that problems are systematically identified, investigated, and resolved. Each stage has specific activities, inputs, and outputs. Stage 1: Problem Detection Problems can be detected through multiple channels: Major incidents: When a major incident occurs, a problem should always be raised  Recurring incidents: Patterns of similar incidents indicate an underlying problem Monitoring events: Alerts that suggest an underlying issue Trend analysis: Patterns identified through data analysis Vendor reports: Suppliers reporting known issues Technical support staff: Internal experts identifying issues  Key question: Is this a one-time incident or a pattern indicating a problem? Stage 2: Problem Logging Once detected, the problem must be properly logged: Core fields : Field Description Subject Title or short summary Description Detailed description including actual behavior, expected behavior, and steps to reproduce Resources Devices on which the problem is identified Category Category to which the problem is mapped Sub Category Subcategory under the category Priority How soon the problem needs to be fixed Additional fields: Requested By: User who requested the problem Assignee Group: User group that manages the problem Assign to: Specific user Application: Applications where the problem is detected Root Cause: Factors on resolution of which incidents can be prevented Work Around: Temporary method for achieving the task Stage 3: Problem Categorization Categorization helps with reporting, routing, and analysis: Product categorization: The IT asset or system affected  Operational categorization: The action or function required  Component/s: Segments of IT infrastructure related to the problem  Good categorization ensures consistency and enables meaningful reporting. Stage 4: Problem Prioritization Priority is based on : Impact: The effect of the problem, usually in regards to service level agreements Urgency: The time available before the business feels the problem's impact Frequency: How often related incidents occur The goal is to prioritize problems that have the greatest business impact. Stage 5: Problem Investigation and Diagnosis This is the root cause analysis phase, where the team determines the underlying cause of the problem: Root cause analysis: Using techniques like Five Whys, Ishikawa diagrams, and Pareto analysis Investigation reason: The trigger for prompting an investigation (e.g., recurring incidents, non-routine incidents)  Cross-functional collaboration: Involving subject matter experts Key question: What is the underlying cause that, if fixed, would prevent recurrence? Stage 6: Creating a Known Error Record When the root cause is identified and a workaround is developed, the problem becomes a "known error" : Known Error documentation: Symptoms of related incidents, root cause, and workarounds Knowledge Base integration: Known errors are added to the Knowledge Base  Incident linking: All related incidents are linked to the known error This is where problem management creates lasting value—by ensuring that when the same issue occurs again, it can be resolved faster. Stage 7: Problem Resolution and Closure The final stage involves implementing a permanent fix: Propose a change: The service desk team proposes a change to the infrastructure to resolve the problem  Implement the fix: Through change management Verify resolution: Confirm the problem is resolved Close the problem: After verification and documentation Testing the fix: Ensure it doesn't introduce new problems. Stage 8: Major Problem Review Team members should carry out in-depth reviews of major problems : Lessons learned: What worked, what didn't Preventive measures: How to prevent similar problems Process improvements: How to improve the problem management process itself Action items: Follow-up activities Visualizing the Lifecycle The problem management workflow should complement these ITIL-recommended activities : Problem investigation Identification of workarounds Recording of known errors Start with the default workflow and adapt it to your specific needs over time. Conclusion The Problem Management lifecycle provides a systematic approach to identifying, investigating, and resolving problems. By following each stage, organizations can ensure that recurring incidents are eliminated and service quality improves over time. Action Items for Your Organization Map your current problem management process against the lifecycle Identify gaps in your process Document the workflow in your ITSM platform Train your team on each stage of the lifecycle Measure completion time for each stage  

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  

Garbage In, Garbage Out — How to Build a Risk Register That Actually Works What Is a Risk Register? A risk register is a formal, centralized repository that records and tracks identified risks. It serves as the single source of truth for risk information across the organization. Essential Risk Register Fields Field Description Risk ID Unique identifier for each risk Risk Description What is the risk? Information Asset What asset is affected? Threat What threat is the source? Vulnerability What vulnerability enables the threat? Impact What is the potential impact? Likelihood How likely is the risk? Inherent Risk Risk before controls Existing Controls What controls are in place? Residual Risk Risk after controls Risk Owner Who is accountable? Control Owner Who implements controls? Risk Treatment How will the risk be treated? Status Current status Review Date When was it last reviewed? Risk Register Best Practices 1. Keep It Current The IT risk register should be regularly updated . Outdated risk registers are worse than none at all. 2. Assign Clear Ownership Every risk should have a risk owner and a control owner . Without ownership, risks won't be managed. 3. Document Risks Clearly Include information asset description and classification, potential threats, impact and likelihood, existing controls, risk owner, implementation owner, and inherent as well as residual risks . 4. Link to Business Impact Every risk should be connected to business impact. Without business context, risk priorities are unclear. 5. Review Regularly Mission-critical and critical information assets should be assessed at least once a year . Common Risk Register Mistakes Mistake Consequence Outdated information Decisions based on obsolete data Missing risks Risks are not managed No ownership No one is accountable No links to business impact Unclear priorities No review schedule Register becomes outdated Risk Register and Audit The risk register should be: Documented and periodically updated in a formal centralized risk register  Regularly updated  Endorsed by the risk committee  Conclusion A well-maintained risk register is the foundation of effective risk management. Organizations that keep their risk registers current, assign clear ownership, and link risks to business impact will make better risk decisions. Action Items for Your Organization Build or update your risk register Assign clear ownership for each risk Link risks to business impact Establish a review cadence Use the risk register to guide risk decisions  

Headline: Which Framework Is Right for Your Organization? — A Complete Guide to Control Frameworks What Is a Control Framework? A control framework is a structured set of practices, principles, and guidelines that helps organizations design, implement, and assess controls. Frameworks provide a common language for controls management and ensure comprehensive coverage. A framework helps you: Identify what controls are needed Design controls effectively Assess control effectiveness Demonstrate compliance Benchmark against peers Major Control Frameworks Framework Primary Focus Best For COSO Internal control, enterprise governance Financial reporting, enterprise risk management COBIT IT governance and management IT processes, alignment with business goals NIST CSF Cybersecurity Cybersecurity risk management NIST SP 800-53 Security and privacy controls Federal systems, government contractors ISO 27001 Information security management Information security management systems COSO Internal Control Framework Overview: The Committee of Sponsoring Organizations (COSO) framework provides a comprehensive model for designing, implementing, and assessing internal controls. It is widely used for financial reporting controls and Sarbanes-Oxley (SOX) compliance. Five Components: Control Environment Risk Assessment Control Activities Information and Communication Monitoring Activities Key Principle for IT Controls: Principle 11 of the COSO framework states: The organization selects and develops general control activities over technology to support the achievement of objectives . Points of Focus: Determines dependency between the use of technology in business processes and technology general controls  Establishes relevant technology infrastructure control activities  Establishes relevant security management process control activities  Establishes relevant technology acquisition, development, and maintenance process control activities  COBIT (Control Objectives for Information and Related Technologies) Overview: COBIT is a comprehensive framework designed to assist organizations in managing their IT systems effectively . Developed by ISACA in 1996, it provides a structured set of best practices that enable managers and IT professionals to evaluate their current IT capabilities and develop strategies for enhancement . Key Features: Aligns IT goals with broader organizational objectives  Optimizes resource use and mitigates risks associated with unregulated IT operations  Organized into four main domains: Planning and Organizing (PO), Acquiring and Implementing (AI), Delivering and Supporting (DS), and Monitoring and Evaluating (ME)  Purpose: COBIT consolidates and harmonizes standards from diverse sources into a critical resource for management, users, and IT auditors . After two decades, COBIT's value is clear as a comprehensive business framework for the governance of enterprise IT . NIST Cybersecurity Framework (CSF) Overview: The NIST CSF provides a policy framework of computer security guidance for how private sector organizations in the United States can assess and improve their ability to prevent, detect, and respond to cyber attacks. Five Functions: Identify Protect Detect Respond Recover ISO 27001 Overview: ISO 27001 specifies the requirements for establishing, implementing, maintaining, and continually improving an information security management system (ISMS). Annex A Controls: Provides a reference set of security controls (114 in the 2013 version) that organizations can select and implement. How to Choose a Framework If Your Organization… Start With Consider Adding Is a government contractor or federal agency NIST SP 800-53 NIST CSF for cybersecurity Needs financial reporting controls COSO COBIT for IT processes Needs ISO 27001 certification ISO 27001 NIST CSF for maturity benchmarking Manages IT governance COBIT COSO for enterprise governance Is a mid-market company starting from scratch NIST CSF 2.0 COBIT or ISO 27001 as you mature Many mature organizations layer frameworks rather than choosing just one. A common approach is COSO for enterprise governance, COBIT for IT management, and NIST CSF for cybersecurity operations. Conclusion Frameworks provide a structured approach to controls management. They offer common language, comprehensive coverage, and benchmarks for maturity. Organizations should select frameworks based on their regulatory requirements, industry, and maturity. Action Items for Your Organization Assess your regulatory and industry requirements Evaluate which frameworks are relevant to your organization Select a primary framework Consider layering frameworks for different purposes Map existing controls to the chosen framework