Integrate IT Risk Into Enterprise Risk

Don’t fear IT risks, integrate them.

EXECUTIVE BRIEF

Analyst Perspective

Having siloed risks is risky business for any enterprise.

Valence Howden Principal Research Director, CIO Practice

Petar Hristov Research Director, Security, Privacy, Risk & Compliance

Ian Mulholland Research Director, Security, Risk & Compliance

Brittany Lutes Senior Research Analyst, CIO Practice

Ibrahim Abdel-Kader Research Analyst, CIO Practice

Every organization has a threshold for risk that should not be exceeded, whether that threshold is defined or not.

In the age of digital, information and technology will undoubtedly continue to expand beyond the confines of the IT department. As such, different areas of the organization cannot address these risks in silos. A siloed approach will produce different ways of identifying, assessing, responding to, and reporting on risk events. Integrated risk management is about embedding IT uncertainty to inform good decision making across the organization.

When risk is integrated into the organization's enterprise risk management program, it enables a single view of all risks and the potential impact of each risk event. More importantly, it provides a consistent view of the risk event in relation to uncertainty that might have once been seemingly unrelated to IT.

And all this can be achieved while remaining within the enterprise’s clearly defined risk appetite.

Executive Summary

Your Challenge

Most organizations fail to integrate IT risks into enterprise risks:

• IT risks, when considered, are identified and classified separately from the enterprise-wide perspective.
• IT is expected to own risks over which they have no authority or oversight.
• Poor behaviors, such as only considering IT risks when conducting compliance or project due diligence, have been normalized.

Common Obstacles

IT leaders have to overcome these obstacles when it comes to integrating risk:

• Making business leaders aware of, involved in, and able to respond to all enterprise risks.
• A lack of data or information being used to support a holistic risk management process.
• A low level of enterprise risk maturity.
• A lack of risk management capabilities.

Info-Tech’s Approach

By leveraging the Info-Tech Integrated Risk approach, your business can better address and embed risk by:

• Understanding gaps in the organization’s current approach to risk management practices.
• Establishing a standardized approach for how IT risks impact the enterprise as a whole.
• Driving a risk-aware organization toward innovation and considering alternative options for how to move forward.
• Helping integrate IT risks into the foundational risk practice.

Info-Tech Insight

Stop avoiding risk – integrate it. This provides a holistic view of uncertainty for the organization to drive innovative new approaches to optimize its ability to respond to risk.

What is integrated risk management?

• Integrated risk management is the process of ensuring all forms of risk information, including information and technology, are considered and included in the enterprise’s risk management strategy.
• It removes the siloed approach to classifying risks related to specific departments or areas of the organization, recognizing that each of those risks is a threat to the overarching enterprise.
• Aggregating the different threats or uncertainty that might exist within an organization allows for informed decisions to be made that align to strategic goals and continue to drive value back to the business.
• By holistically considering the different risks, the organization can make informed decisions on the best course of action that will reduce any negative impacts associated with the uncertainty and increase the overall value.

Enterprise Risk Management (ERM)

• IT
• Security
• Digital
• Vendor/Third Party
• Other

Enterprise risk management is the practice of identifying and addressing risks to your organization and using risk information to drive better decisions and better opportunities.

IT risk is enterprise risk

IT risks have a direct and often aggregated impact on enterprise risks and opportunities in the same way other business risks can. This relationship must be understood and addressed through integrated risk management to ensure a consistent approach to risk.

Your challenge

Embedding IT risks into the enterprise risk management program is challenging because:

• Most organizations classify risks based on the departments or areas of the business where the uncertainty is likely to happen.
• Unnecessary expectations are placed on the IT department to own risks over which they have no authority or oversight.
• Risks are often only identified when conducting due diligence for a project or ensuring compliance with regulations and standards.

Risk-mature organizations have a unique benefit in that they often have established an overarching governance framework and embedded risk awareness into the culture.

35% — Only 35% of organizations had embraced ERM in 2020. (Source: AICPA and NC State Poole College of Management)

12% — Only 12% of organizations are leveraging risk as a tool to their strategic advantage. (Source: AICPA and NC State Poole College of Management)

Common obstacles

These barriers make integrating IT risks difficult to address for many organizations:

• IT risks are not seen as enterprise risks.
• The organization’s culture toward risk is not defined.
• The organization’s appetite and threshold for risk are not defined.
• Each area of the organization has a different method of identifying, assessing, and responding to risk events.
• Access to reliable and informative data to support risk management is difficult to obtain.
• Leadership does not see the business value of integrating risk into a single management program.
• The organization’s attitudes and behaviors toward risk contradict the desired and defined risk culture.
• Skills, training, and resources to support risk management are lacking, let alone those to support integrated risk management.

Integrating risks has its challenges

62% — Accessing and disseminating information is the main challenge for 62% of organizations maturing their organizational risk management. (Source: OECD)

20-28% — Organizations with access to machine learning and analytics to address future risk events have 20 to 28% more satisfaction. (Source: Accenture)

Integrate Risk and Use It to Your Advantage

Accelerate and optimize your organization by leveraging meaningful risk data to make intelligent enterprise risk decisions.

Risk management is more than checking an audit box or demonstrating project due diligence.

Risk Drivers Audit & compliance Preserve value & avoid loss Previous risk impact driver Major transformation Strategic opportunities		Only 7% of organizations are in a “leading” or “aspirational” level of risk maturity. (OECD, 2021)	63% of organizations struggle when it comes to defining their appetite toward strategy related risks. (“Global Risk Management Survey,” Deloitte, 2021)	Late adopters of risk management were 70% more likely to use instinct over data or facts to inform an efficient process. (Clear Risk, 2020)	55% of organizations have little to no training on ERM to properly implement such practices. (AICPA, NC State Poole College of Management, 2021)
		1. Assess Enterprise Risk Maturity	3. Build a Risk Management Program Plan	4. Establish Risk Management Processes	5. Implement a Risk Management Program
		2. Determine Authority with Governance Unfortunately, less than 50% of those in risk focused roles are also in a governance role where they have the authority to provide risk oversight. (Governance Institute of Australia, 2020)
IT can improve the maturity of the organization’s risk governance and help identify risk owners who have authority and accountability. Governance and related decision making is optimized with integrated and aligned risk data.			ERM incorporates the different types of risk, including IT, security, digital, vendor, and other risk types. The program plan is meant to consider all the major risk types in a unified approach.		Implementation of an integrated risk management program requires ongoing access to risk data by those with decision making authority who can take action.

Integrated Risk Mapping — Downside Risk Focus

Integrated Risk Mapping — Downside and Upside Risk

Third-Party Risk Example

Insight Summary

Overarching insight

Stop fearing risk – integrate it. Integration leads to opportunities for organizations to embrace innovation and new digital technologies as well as reducing operational costs and simplifying reporting.

Govern risk strategically

Governance of risk management for information- and technology-related events is often misplaced. Just because it's classified as an IT risk does not mean it shouldn’t be owned by the board or business executive.

Assess risk maturity

Integrating risk requires a baseline of risk maturity at the enterprise level. IT can push integrating risks, but only if the enterprise is willing to adopt the attitudes and behaviors that will drive the integrated risk approach.

Manage risk

It is not a strategic decision to have different areas of the organization manage the risks perceived to be in their department. It’s the easy choice, but not the strategic one.

Implement risk management

Different areas of an enterprise apply risk management processes differently. Determining a single method for identification, assessment, response, and monitoring can ensure successful implementation of enterprise risk management.

Tactical insight

Good risk management will consider both the positives and negatives associated with a risk management program by recognizing both the upside and downside of risk event impact and likelihood.

Integrated risk benefits

Measure the value of integrating risk

• Reduce Operating Costs

  • Organizations can reduce their risk operating costs by 20 to 30% by adopting enterprise-wide digital risk initiatives (McKinsey & Company).

• Increase Cybersecurity Threat Preparedness

  • Increase the organization’s preparedness for cybersecurity threats. 79% of organizations that were impacted by email threats in 2020 were not prepared for the hit (Diligent)

• Increase Risk Management’s Impact to Drive Strategic Value

  • Currently, only 3% of organizations are extensively using risk management to drive their unique competitive advantage, compared to 35% of companies who do not use it at all (AICPA & NC State Poole College of Management).

• Reduce Lost Productivity for the Enterprise

  • Among small businesses, 76% are still not considering purchasing cyberinsurance in 2021, despite the fact that ransomware attacks alone cost Canadian businesses $5.1 billion in productivity in 2020 (Insurance Bureau of Canada, 2021).

“31% of CIO’s expected their role to expand and include risk management responsibilities.” (IDG “2021 State of the CIO,” 2021)

Make integrated risk management sustainable

Assessment

Assess your organization’s method of addressing risk management to determine if integrated risk is possible

Assessing the organization’s risk maturity

Mature or not, integrated risk management should be a consideration for all organizations The first step to integrating risk management within the enterprise is to understand the organization’s readiness to adopt practices that will enable it to successfully integrate information. In 2021, we saw enterprise risk management assessments become one of the most common trends, particularly as a method by which the organization can consolidate the potential impacts of uncertainties or threats (Lawton, 2021). A major driver for this initiative was the recognition that information and technology not only have enterprise-wide impacts on the organization’s risk management but that IT has a critical role in supporting processes that enable effective access to data/information. A maturity assessment has several benefits for an organization: It ensures there is alignment throughout the organization on why integrated risk is the right approach to take, it recognizes the organization’s current risk maturity, and it supports the organization in defining where it would like to go.

Maturity should inform your approach to risk management

The outcome of the risk maturity assessment should inform how risk management is approached within the organization.

For organizations with a low maturity, remaining superficial with risk will offer more benefits and align to the enterprise’s risk tolerance and appetite. This might mean no integrated risk is taking place.

However, organizations that have higher risk maturity should begin to integrate risk information. These organizations can identify the nuances that would affect the severity and impact of risk events.

Integrated Risk Maturity Assessment

The purpose of the Integrated Risk Maturity Assessment is to assess the organization's current maturity and readiness for integrated risk management (IRM).

Frequently and continually assessing your organization’s maturity toward integrated risk ensures the right risk management program can be adopted by your organization.

Integrated Risk Maturity Assessment A simple tool to understand if your organization is ready to embrace integrated risk management by measuring maturity across four key categories: Context & Strategic Direction, Risk Culture & Authority, Risk Management Process, and Risk Program Optimization

Use the results from this integrated risk maturity assessment to determine the type of risk management program that can and should be adopted by your organization.

Some organizations will need to remain siloed and focused on IT risk management only, while others will be able to integrate risk-related information to start enabling automatic controls that respond to this data.

Tactics to Retain IT Talent

Keep talent from walking out the door by discovering and addressing moments that matter and turnover triggers.

Executive Summary

Your Challenge

Many organizations are facing an increase in voluntary turnover as low unemployment, a lack of skilled labor, and a rise in the number of vacant roles have given employees more employment choices.

Common Obstacles

Regrettable turnover is impacting organizational productivity and leading to significant costs associated with employee departures and the recruitment required to replace them.

Many organizations tackle retention from an engagement perspective: Increase engagement to improve retention. This approach doesn't consider the whole problem.

Info-Tech's Approach

Build the case for creating retention plans by leveraging employee data and feedback to identify the key reasons for turnover that need to be addressed.

Target employee segments and work with management to develop solutions to retain top talent.

Info-Tech Insight

Engagement surveys mask the volatility of the employee experience and hide the reason why individual employees leave. You must also talk to employees to understand the moments that matter and engage managers to understand turnover triggers.

This research addresses regrettable turnover

Low unemployment and rising voluntary turnover makes it critical to focus on retention

As the economy continues to recover from the pandemic, unemployment continues to trend downward even with a looming recession. This leaves more job openings vacant, making it easier for employees to job hop.

With more employees voluntarily choosing to leave jobs, it is more important than ever for organizations to identify key employees they want to retain and put plans in place to keep them.

Retention is a challenge for many organizations

The number of HR professionals citing retention/turnover as a top workforce management challenge is increasing, and it is now the second highest recruiting priority ("2020 Recruiter Nation Survey," Jobvite, 2020).

65% of employees believe they can find a better position elsewhere (Legaljobs, 2021). This is a challenge for organizations in that they need to find ways to ensure employees want to stay at the organization or they will lose them, which results in high turnover costs.

Executives and IT are making retention and turnover – two sides of the same coin – a priority because they cost organizations money.

• 87% of HR professionals cited retention/turnover as a critical and high priority for the next few years (TINYpulse, 2020).
• $630B The cost of voluntary turnover in the US (Work Institute, 2020).
• 66% of organizations consider employee retention to be important or very important to an organization (PayScale, 2019).

Improving retention leads to broad-reaching organizational benefits

Cost savings: the price of turnover as a percentage of salary

• 33% Improving retention can result in significant cost savings. A recent study found turnover costs, on average, to be around a third of an employee's annual salary (SHRM, 2019).
• 37.9% of employees leave their organization within the first year. Employees who leave within the first 90 days of being hired offer very little or no return on the investment made to hire them (Work Institute, 2020).

Improved performance

Employees with longer tenure have an increased understanding of an organization's policies and processes, which leads to increased productivity (Indeed, 2021).

Prevents a ripple effect

Turnover often ripples across a team or department, with employees following each other out of the organization (Mereo). Retaining even one individual can often have an impact across the organization.

Transfer of knowledge

Retaining key individuals allows them to pass it on to other employees through communities of practice, mentoring, or other knowledge-sharing activities.

Info-Tech Insight

Improving retention goes beyond cost savings: Employees who agree with the statement "I expect to be at this organization a year from now" are 71% more likely to put in extra hours and 32% more likely to accomplish more than what is expected of their role (McLean & Company Engagement Survey, 2021; N=77,170 and 97,326 respectively).

However, the traditional engagement-focused approach to retention is not enough

Employee engagement is a strong driver of retention, with only 25% of disengaged employees expecting to be at their organization a year from now compared to 92% of engaged employees (McLean & Company Engagement Survey, 2018-2021; N=117,307).

Average employee Net Promoter Score (eNPS)

Individual employee Net Promoter Scores (eNPS)

However, engagement surveys mask the volatility of the employee experience and hide the reason why individual employees leave.

This analysis of McLean & Company's engagement survey results shows that while an organization's average employee net promoter score (eNPS) stays relatively static, at an individual level there is a huge amount of volatility.

This demonstrates the need for an approach that is more capable of responding to or identifying employees' in-the-moment needs, which an annual engagement survey doesn't support.

Turnover triggers and moments that matter also have an impact on retention

Retention needs to be monitored throughout the employee lifecycle. To address the variety of issues that can appear, consider three main paths to turnover:

1. Employee engagement – areas of low engagement.
2. Turnover triggers that can quickly lead to departures.
3. Moments that matter in the employee experience (EX).

Employee engagement

Engagement drivers are strong predictors of turnover.

Employees who are highly engaged are 3.6x more likely to believe they will be with the organization 12 months from now than disengaged employees (McLean & Company Engagement Survey, 2018-2021; N=117,307).

Turnover triggers

Turnover triggers are events that act as shocks or catalysts that quickly lead to an employee's departure.

Turnover triggers are a cause for voluntary turnover more often than accumulated issues (Lee et al.).

Moments that matter

Employee experience is the employee's perception of the accumulation of moments that matter within their employee lifecycle.

Retention rates increase from 21% to 44% when employees have positive experiences in the following categories: belonging, purpose, achievement, happiness, and vigor at work. (Workhuman, 2020).

While managers do not directly impact turnover, they do influence the three main paths to turnover

Research shows managers do not appear as one of the common reasons for employee turnover.

Top five most common reasons employees leave an organization (McLean & Company, Exit Survey, 2018-2021; N=107 to 141 companies,14,870 to 19,431 responses).

However, managers can still have a huge impact on the turnover of their team through each of the three main paths to turnover:

Employee engagement

Employees who believe their managers care about them as a person are 3.3x more likely to be engaged than those who do not (McLean & Company, 2021; N=105,186).

Turnover triggers

Managers who are involved with and aware of their staff can serve as an early warning system for triggers that lead to turnover too quickly to detect with data.

Moments that matter

Managers have a direct connection with each individual and can tailor the employee experience to meet the needs of the individuals who report to them.

Gallup has found that 52% of exiting employees say their manager could have done something to prevent them from leaving (Gallup, 2019). Do not discount the power of managers in anticipating and preventing regrettable turnover.

Addressing engagement, turnover triggers, and moments that matter is the key to retention

Info-Tech Insight

HR traditionally seeks to examine engagement levels when faced with retention challenges, but engagement is only a part of the full picture. You must also talk to employees to understand the moments that matter and engage managers to understand turnover triggers.

Follow Info-Tech's two-step process to create a retention plan

1. Identify Reasons for Regrettable Turnover

2. Select Solutions and Create an Action Plan

Step 1

Identify Reasons for Regrettable Turnover

After completing this step you will have:

• Analyzed and documented why employees join, stay, and leave your organization.
• Identified common themes and employee needs.
• Conducted employee focus groups and prioritized employee needs.

Step 1 focuses on analyzing existing data and validating it through focus groups

Info-Tech Insight

IT managers often have insights into where and why retention is an issue through their day-to-day work. Gathering detailed quantitative and qualitative data provides credibility to these insights and is key to building a business case for action. Keep an open mind and allow the data to inform your gut feeling, not the other way around.

Gather data to better understand why employees join, stay, and leave

Start to gather and examine additional data to accurately identify the reason(s) for high turnover. Begin to uncover the story behind why these employees join, stay, and leave your organization through themes and trends that emerge.

Look for these icons throughout step 2.		Why do candidates join your organization?
	Why do employees stay with your organization?
	Why do employees leave your organization?

For more information on analysis, visualization, and storytelling with data, see Info-Tech's Start Making Data-Driven People Decisions blueprint.

Employee feedback data to look at includes:

• Employee Experience Monitor
• Employee Engagement Survey

Gather insights through:

• Focus groups
• Verbatim comments
• Exit interviews
• Using the employee value proposition (EVP) as a filter (does it resonate with the lived experience of employees?)

Prepare to draw themes and trends from employee data throughout step 1.

Uncover employee needs and reasons for turnover by analyzing employee feedback data.

• Look for trends (e.g. new hires join for career opportunities and leave for the same reason, or most departments have strong work-life balance scores in engagement data).
• Review if there are recurring issues being raised that may impact turnover.
• Group feedback to highlight themes (e.g. lack of understanding of EVP).
• Identify which key employee needs merit further investigation or information.

Classify where key employee needs fall within the employee lifecycle diagram in tab 2 of the Retention Plan Workbook. This will be used in step 2 to pinpoint and prioritize solutions.

Info-Tech Insight

The employee lifecycle is a valuable way to analyze and organize engagement pain points, moments that matter, and turnover triggers. It ensures that you consider the entirety of an employee's tenure and the different factors that lead to turnover.

Examine new hire data and begin to document emerging themes

While conducting a high-level analysis of new hire data, look for these three key themes impacting retention:

Issues or pain points that occurred during the hiring process.

Reasons why employees joined your organization.

The experience of their first 90 days. This can include their satisfaction with the onboarding process and their overall experience with the organization.

Themes will help to identify areas of strength and weakness organization-wide and within key segments. Document in tab 3 of the Retention Plan Workbook.

1. Start by isolating the top reasons employees joined your organization. Ask:
   • Do the reasons align with the benefits you associate with working at your organization?
   • How might this impact your EVP?
   • If you use a new hire survey, look at the results for the following questions:
   • For which of the following reasons did you apply to this organization?
   • For what reasons did you accept the job offer with this organization?
2. then, examine other potential problem areas that may not be covered by your new hire survey, such as onboarding or the candidate experience during the hiring process.
   • If you conduct a new hire survey, look at the results in the following sections:
     • Candidate Experience
     • Acclimatization
     • Training and Development
     • Defining Performance Expectations

Analyze engagement data to identify areas of strength that drive retention

Employees who are engaged are 3.6x more likely to believe they will be with the organization 12 months from now (McLean & Company Engagement Survey, 2018-2021; N=117,307). Given the strength of this relationship, it is essential to identify areas of strength to maintain and leverage.

1. Look at the highest-performing drivers in your organization's employee engagement survey and drivers that fall into the "leverage" and "maintain" quadrants of the priority matrix.
   • These drivers provide insight into what prompts broader groups of employees to stay.

1. Look into what efforts have been made to maintain programs, policies, and practices related to these drivers and ensure they are consistent across the entire organization.
2. Document trends and themes related to engagement strengths in tab 2 of the Retention Plan Workbook.

If you use Info-Tech's Engagement Survey, look in detail at what are classified as "Retention Drivers": total compensation, working environment, and work-life balance.

Identify areas of weakness that drive turnover in your engagement data

1. Look at the lowest-performing drivers in your organization's employee engagement survey and drivers that fall into the "improve" and "evaluate" quadrants of the priority matrix.
   • These drivers provide insight into what pushes employees to leave the organization.
2. Delve into organizational efforts that have been made to address issues with the programs, policies, and practices related to these drivers. Are there any projects underway to improve them? What are the barriers preventing improvements?
3. Document trends and themes related to engagement weaknesses in tab 2 of the Retention Plan Workbook.

If you use a product other than Info-Tech's Engagement Survey, your results will look different. The key is to look at areas of weakness that emerge from the data.

If you use Info-Tech's Engagement Survey, look in detail at what are classified as "Retention Drivers": total compensation, working environment, and work-life balance.

Mine exit surveys to develop an integrated, holistic understanding of why employees leave

Conduct a high-level analysis of the data from your employee exit diagnostic. While analyzing this data, consider the following:

• What are the trends and quantitative data about why employees leave your organization that may illuminate employee needs or issues at specific points throughout the employee lifecycle?
• What are insights around your key segments? Data on key segments is easily sliced from exit survey results and can be used as a starting point for digging deeper into retention issues for specific groups.
• Exit surveys are an excellent starting point. However, it is valuable to validate the data gathered from an exit survey using exit interviews.

1. Isolate results for key segments of employees to target with retention initiatives (e.g. by age group or by department).
2. Identify data trends or patterns over time; for example, that compensation factors have been increasing in importance.
3. Document trends and themes taken from the exit survey results in tab 2 of the Retention Plan Workbook.

If your organization conducts exit interviews, analyze the results alongside or in lieu of exit survey data.

Compare new hire data with exit data to identify patterns and insights

Determine if new hire expectations weren't met, prompting employees to leave your organization, to help identify where in the employee lifecycle issues driving turnover may be occurring.

1. Look at your new hire data for the top reasons employees joined your organization.
   • McLean & Company's New Hire Survey database shows that the top three reasons candidates accept job offers on average are:
     1. Career opportunities
     2. Nature of the job
     3. Development opportunities
2. Next, look at your exit data and the top reasons employees left your organization.
   1. McLean & Company's Exit Survey database shows that the top three reasons employees leave on average are:
      1. Opportunities for career advancement
      2. Base pay
      3. Satisfaction with my role and responsibilities
3. Examine the results and ask:
   • Is there a link between why employees join and leave the organization?
   • Did they cite the same reasons for joining and for leaving?
   • What do the results say about what your employees do and do not value about working at your organization?
4. Document the resulting insights in tab 2 of the Retention Plan Workbook.

Example:

A result where employees are leaving for the same reason they're joining the organization could signal a disconnect between your organization's employee value proposition and the lived experience.

Revisit your employee value proposition to uncover misalignment

Your employee value proposition (EVP), formal or informal, communicates the value your organization can offer to prospective employees.

If your EVP is mismatched with the lived experience of your employees, new hires will be in for a surprise when they start their new job and find out it isn't what they were expecting.

Forty-six percent of respondents who left a job within 90 days of starting cited a mismatch of expectations about their role ("Job Seeker Nation Study 2020," Jobvite, 2020).

1. Use the EVP as a filter through which you look at all your employee feedback data. It will help identify misalignment between the promised and the lived experience.
2. If you have EVP documentation, start there. If not, go to your careers page and put yourself in the shoes of a candidate. Ask what the four elements of an EVP look like for candidates:
   • Compensation and benefits
   • Day-to-day job elements
   • Working conditions
   • Organizational elements
3. Next, compare this to your own day-to-day experiences. Does it differ drastically? Are there any contradictions with the lived experience at your organization? Are there misleading statements or promises?
4. Document any insights or patterns you uncover in tab 2 of the Retention Plan Workbook.

Conduct focus groups to examine themes

Through focus groups, explore the themes you have uncovered with employees to discover employee needs that are not being met. Addressing these employee needs will be a key aspect of your retention plan.

Identify employee groups who will participate in focus groups:

• Incorporate diverse perspectives (e.g. employees, managers, supervisors).
• Include employees from departments and demographics with strong and weak engagement for a full picture of how engagement impacts your employees.
• Invite boomerang employees to learn why an individual might return to your organization after leaving.

Customize Info-Tech's Standard Focus Group Guide based on the themes you have identified in tab 3 of the Retention Plan Workbook.

The goal of the focus group is to learn from employees and use this information to design or modify a process, system, or other solution that impacts retention.

Focus questions on the employees' personal experience from their perspective.

Key things to remember:

• It is vital for facilitators to be objective.
• Keep an open mind; no feelings are wrong.
• Beware of your own biases.
• Be open and share the reason for conducting the focus groups.

Info-Tech Insight

Maintaining an open dialogue with employees will help flesh out the context behind the data you've gathered and allow you to keep in mind that retention is about people first and foremost.

Empathize with employees to identify moments that matter

(Based on Stanford d.school Empathy Map Method)

Distill employee needs into priority issues to address first

Take employee needs revealed by your data and focus groups and prioritize three to five needs.

Select a limited number of employee needs to develop solutions to ensure that the scope of the project is feasible and that the resources dedicated to this project are not stretched too thin. The remaining needs should not be ignored – act on them later.

Share the needs you identify with stakeholders so they can support prioritization and so you can confirm their buy-in and approval where necessary.

Ask yourself the following questions to determine your priority employee needs:

• Which needs will have the greatest impact on turnover?
• Which needs have the potential to be an easy fix or quick win?
• Which themes or trends came up repeatedly in different data sources?
• Which needs evoked particularly strong or negative emotions in the focus groups?

In the Retention Plan Workbook, distill employee needs on tab 2 into three to five priorities on tab 5.

Step 2

Select Solutions and Create an Action Plan

After completing this step, you will have:

• Selected and prioritized solutions to address employee needs.
• Created a plan to launch stay interviews.
• Built an action plan to implement solutions.

Select IT-owned solutions and implement people leader–driven initiatives

Solutions

First, select and prioritize solutions to address employee needs identified in the previous step. These solutions will address reasons for turnover that influence employee engagement and moments that matter.

• Brainstorm solutions using the Retention Solutions Catalog as a starting point. Select a longlist of solutions to address your priority needs.
• Prioritize the longlist of solutions into a manageable number to act on.

People leaders

Next, create a plan to launch stay interviews to increase managers' accountability in improving retention. Managers will be critical to solving issues stemming from turnover triggers.

• Clarify the importance of harnessing the influence of people leaders in improving retention.
• Discover what might cause individual employees to leave through stay interviews.
• Increase trust in managers through training.

Action plan

Finally, create an action plan and present to senior leadership for approval.

Look for these icons in the top right of slides in this step.

Select solutions to employee needs, starting with the Retention Solutions Catalog

Based on the priority needs you have identified, use the Retention Solutions Catalog to review best-practice solutions for pain points associated with each stage of the lifecycle.

Use this tool as a starting point, adding to it and iterating based on your own experience and organizational culture and goals.

Use Info-Tech's Retention Solutions Catalog to start the brainstorming process and produce a shortlist of potential solutions that will be prioritized on the next slide.

Info-Tech Insight

Unless you have the good fortune of having only a few pain points, no single initiative will completely solve your retention issues. Combine one or two of these broad solutions with people-leader initiatives to ensure employee needs are addressed on an individual and an aggregate level.

Prioritize solutions to be implemented

Target efforts accordingly

Quick wins are high-impact, low-effort initiatives that will build traction and credibility within the organization.

Long-term initiatives require more time and need to be planned for accordingly but will still deliver a large impact. Review the planning horizon to determine how early these need to begin.

Re-evaluate low-impact and low-effort initiatives and identify ones that either support other higher impact initiatives or have the highest impact to gain traction and credibility. Look for low-hanging fruit.

Deprioritize initiatives that will take a high degree of effort to deliver lower-value results.

When assessing the impact of potential solutions, consider:

• How many critical segments or employees will this solution affect?
• Is the employee need it addresses critical, or did the solution encompass several themes in the data you analyzed?
• Will the success of this solution help build a case for further action?
• Will the solution address multiple employee needs?

Info-Tech Insight

It's better to master a few initiatives than under-deliver on many. Start with a few solutions that will have a measurable impact to build the case for further action in the future.

Solutions

	Low Impact	Medium Impact	Large Impact
Large Effort
Medium Effort
Low Effort

Use tab 3 of the Retention Plan Workbook to prioritize your shortlist of solutions.

Harness the influence of people leaders to improve employee retention

Leaders at all levels have a huge impact on employees.

Effective people leaders:

• Manage work distribution.
• Create a motivating work environment.
• Provide development opportunities.
• Ensure work is stimulating and challenging, but not overwhelming.
• Provide clear, actionable feedback.
• Recognize team member contributions.
• Develop positive relationships with their teams.
• Create a line of sight between what the employee is doing and what the organization's objectives are.

Support leaders in recommitting to their role as people managers through Learning & Development initiatives with particular emphasis on coaching and building trust.

For coaching training, see Info-Tech's Build a Better Manager: Team Essentials – Feedback and Coaching training deck.

For more information on supporting managers to become better people leaders, see Info-Tech's Build a Better Manager: Manage Your People blueprint.

"HR can't fix turnover. But leaders on the front line can."
– Richard P. Finnegan, CEO, C-Suite Analytics

Equip managers to conduct regular stay interviews to address turnover triggers

Managers often have the most visibility into their employees' personal and work lives and have a key opportunity to anticipate and address turnover triggers.

Stay interviews are an effective way of uncovering potential retention issues and allowing managers to act as an early warning system for turnover triggers.

Examples of common turnover triggers and potential manager responses:

• Moving, creating a long commute to the office.
  • Through stay interviews, a manager can learn that a long commute is an issue and can help find workarounds such as flexible/remote work options.
• Not receiving an expected promotion.
  • A trusted manager can anticipate issues stemming from this, discuss why the decision was made, and plan development opportunities for future openings.

Stay interview best practices

1. Conducted by an employee's direct manager.
2. Happen regularly as a part of an ongoing process.
3. Based on the stay interview, managers produce a turnover forecast for each direct report.
   1. The method used by stay interview expert Richard P. Finnegan is simple: red for high risk, yellow for medium, and green for low.
4. Provide managers with training and a rough script or list of questions to follow.
   1. Use and customize Info-Tech's Stay Interview Guide to provide a guide for managers on how to conduct a stay interview.
5. Managers use the results to create an individualized retention action plan made up of concrete actions the manager and employee will take.

Sources: Richard P. Finnegan, CEO, C-Suite Analytics; SHRM

Build an action plan to implement the retention plan

For each initiative identified, map out timelines and actions that need to be taken.

When building actions and timelines:

• Refer to the priority needs you identified in tab 4 of the Retention Plan Workbook and ensure they are addressed first.
• Engage internal stakeholders who will be key to the development of the initiatives to ensure they have sufficient time to complete their deliverables.
  • For example, if you conduct manager training, Learning & Development needs to be involved in the development and launch of the program.
• Include a date to revisit your baseline retention and engagement data in your project milestones.
• Designate process owners for new processes such as stay interviews.

Plan for stay interviews by determining:

• Whether stay interviews will be a requirement for all employees.
• How much flexibility managers will have with the process.
• How you will communicate the stay interview approach to managers.
• If manager training is required.
• How managers should record stay interview data and how you will collect this data from them as a way to monitor retention issues.
  • For example, managers can share their turnover forecasts and action plans for each employee.

Be clear about manager accountabilities for initiatives they will own, such as stay interviews. Plan to communicate the goals and timelines managers will be asked to meet, such as when they must conduct interviews or their responsibility to follow up on action items that come from interviews.

Track project success to iterate and improve your solutions

Analyze measurements

• Regularly remeasure your engagement and retention levels to identify themes and trends that provide insights into program improvements.
• For example, look at the difference in manager relationship score to see if training has had an impact, or look at changes in critical segment turnover to calculate cost savings.

Revisit employee and manager feedback

• After three to six months, conduct additional surveys or focus groups to determine the success of your initiatives and opportunities for improvement. Tweak the program, including stay interviews, based on manager and employee feedback.

Iterate frequently

• Revisit your initiatives every two or three years to determine if a refresh is necessary to meet changing organizational and employee needs and to update your goals and targets.

Key insights

Workshop Overview

Contact your account representative for more information.
workshops@infotech.com 1-888-670-8889

Workshop Overview

Contact your account representative for more information.
workshops@infotech.com 1-888-670-8889

Info-Tech offers various levels of support to best suit your needs

DIY Toolkit

“Our team has already made this critical project a priority, and we have the time and capability, but some guidance along the way would be helpful.”

Guided Implementation

“Our team knows that we need to fix a process, but we need assistance to determine where to focus. Some check-ins along the way would help keep us on track.”

Workshop

“We need to hit the ground running and get this project kicked off immediately. Our team has the ability to take this over once we get a framework and strategy in place.”

Consulting

“Our team does not have the time or the knowledge to take this project on. We need assistance through the entirety of this project.”

Diagnostics and consistent frameworks used throughout all four options

Research Contributors and Experts

Jeff Bonnell
VP HR
Info-Tech Research Group

Phillip Kotanidis
CHRO
Michael Garron Hospital

Michael McGuire
Director, Organizational Development
William Osler Health System

Dr. Iris Ware
Chief Learning Officer
City of Detroit

Richard P. Finnegan
CEO
C-Suite Analytics

Dr. Thomas Lee
Professor of Management
University of Washington

Jane Moughon
Specialist in increasing profits, reducing turnover, and maximizing human potential in manufacturing companies

Lisa Kaste
Former HR Director
Citco

Piyush Mathur
Head of Workforce Analytics
Johnson & Johnson

Gregory P. Smith
CEO
Chart Your Course

Works Cited

"17 Surprising Statistics about Employee Retention." TINYpulse, 8 Sept. 2020. Web.
"2020 Job Seeker Nation Study." Jobvite, April 2020. Web.
"2020 Recruiter Nation Survey." Jobvite, 2020. Web.
"2020 Retention Report: Insights on 2019 Turnover Trends, Reasons, Costs, & Recommendations." Work Institute, 2020. Web.
"25 Essential Productivity Statistics for 2021." TeamStage, 2021. Accessed 22 Jun. 2021.
Agovino, Theresa. "To Have and to Hold." SHRM, 23 Feb. 2019. Web.
"Civilian Unemployment Rate." Bureau of Labor Statistics, June 2020. Web.
Foreman, Paul. "The domino effect of chief sales officer turnover on salespeople." Mereo, 19 July 2018. Web.
"Gross Domestic Product." U.S. Bureau of Economic Analysis, 27 May 2021. Accessed 22 Jun. 2020.
Kinne, Aaron. "Back to Basics: What is Employee Experience?" Workhuman, 27August 2020. Accessed 21 Jun. 2021.
Lee, Thomas W, et al. "Managing employee retention and turnover with 21st century ideas." Organizational Dynamics, vol 47, no. 2, 2017, pp. 88-98. Web.
Lee, Thomas W. and Terence R. Mitchell. "Control Turnover by Understanding its Causes." The Blackwell Handbook of Principles of Organizational Behaviour. 2017. Print.
McFeely, Shane, and Ben Wigert. "This Fixable Problem Costs U.S. Businesses $1 Trillion." Gallup. 13 March 2019. Web.
"Table 18. Annual Quit rates by Industry and Region Not Seasonally Adjusted." Bureau of Labor Statistics. June 2021. Web.
"The 2019 Compensation Best Practices Report: Will They Stay or Will They Go? Employee Retention and Acquisition in an Uncertain Economy." PayScale. 2019. Web.
Vuleta, Branka. "30 Troubling Employee Retention Statistics." Legaljobs. 1 Feb. 2021. Web.
"What is a Tenured Employee? Top Benefits of Tenure and How to Stay Engaged as One." Indeed. 22 Feb. 2021. Accessed 22 Jun. 2021.

Create a Right-Sized Disaster Recovery Plan

Close the gap between your DR capabilities and service continuity requirements.

ANALYST PERSPECTIVE

An effective disaster recovery plan (DRP) is not just an insurance policy.

"An effective DRP addresses common outages such as hardware and software failures, as well as regional events, to provide day-to-day service continuity. It’s not just insurance you might never cash in. Customers are also demanding evidence of an effective DRP, so organizations without a DRP risk business impact not only from extended outages but also from lost sales. If you are fortunate enough to have executive buy-in, whether it’s due to customer pressure or concern over potential downtime, you still have the challenge of limited time to dedicate to disaster recovery (DR) planning. Organizations need a practical but structured approach that enables IT leaders to create a DRP without it becoming their full-time job."

Frank Trovato,

Research Director, Infrastructure

Info-Tech Research Group

Is this research for you?

This Research Is Designed For:

• Senior IT management responsible for executing DR.
• Organizations seeking to formalize, optimize, or validate an existing DRP.
• Business continuity management (BCM) professionals leading DRP development.

This Research Will Help You:

• Create a DRP that is aligned with business requirements.
• Prioritize technology enhancements based on DR requirements and risk-impact analysis.
• Identify and address process and technology gaps that impact DR capabilities and day-to-day service continuity.

This Research Will Also Assist:

• Executives who want to understand the time and resource commitment required for DRP.
• Members of BCM and crisis management teams who need to understand the key elements of an IT DRP.

This Research Will Help Them:

• Scope the time and effort required to develop a DRP.
• Align business continuity, DR, and crisis management plans.

Executive summary

Situation

• Any time a natural disaster or major IT outage occurs, it increases executive awareness and internal pressure to create a DRP.
• Industry standards and government regulations are driving external pressure to develop business continuity and IT DR plans.
• Customers are asking suppliers and partners to provide evidence that they have a workable DRP before agreeing to do business.

Complication

• Traditional DRP templates are onerous and result in a lengthy, dense plan that might satisfy auditors, but will not be effective in a crisis.
• The myth that a DRP is only for major disasters leaves organizations vulnerable to more common incidents.
• The growing use of outsourced infrastructure services has increased reliance on vendors to meet recovery timeline objectives.

Resolution

• Create an effective DRP by following a structured process to discover current capabilities and define business requirements for continuity:
  • Define appropriate objectives for service downtime and data loss based on business impact.
  • Document an incident response plan that captures all of the steps from event detection to data center recovery.
  • Create a DR roadmap to close gaps between current DR capabilities and recovery objectives.

Info-Tech Insight

1. At its core, DR is about ensuring service continuity. Create a plan that can be leveraged for both isolated and catastrophic events.
2. Remember Murphy’s Law. Failure happens. Focus on improving overall resiliency and recovery, rather than basing DR on risk probability analysis.
3. Cost-effective DR and service continuity starts with identifying what is truly mission critical so you can focus resources accordingly. Not all services require fast failover.

An effective DRP is critical to reducing the cost of downtime

If you don’t have an effective DRP when failure occurs, expect to face extended downtime and exponentially rising costs due to confusion and lack of documented processes.

Potential Lost Revenue

The impact of downtime tends to increase exponentially as systems remain unavailable (graph at left). A current, tested DRP will significantly improve your ability to execute systems recovery, minimizing downtime and business impact. Without a DRP, IT is gambling on its ability to define and implement a recovery strategy during a time of crisis. At the very least, this means extended downtime – potentially weeks or months – and substantial business impact.

Adapted from: Philip Jan Rothstein, 2007

Cost of Downtime for the Fortune 1000

Cost of unplanned apps downtime per year: $1.25B to $2.5B.

Cost of critical apps failure per hour: $500,000 to $1M.

Cost of infrastructure failure per hour: $100,000.

35% reported to have recovered within 12 hours.

17% of infrastructure failures took more than 24 hours to recover.

13% of application failures took more than 24 hours to recover.

Source: Stephen Elliot, 2015

Info-Tech Insight

The cost of downtime is rising across the board, and not just for organizations that traditionally depend on IT (e.g. e-commerce). Downtime cost increase since 2010:

Hospitality: 129% increase

Transportation: 108% increase

Media organizations: 104% increase

An effective DRP also sets clear recovery objectives that align with system criticality to optimize spend

Take a practical approach that creates a more concise and actionable DRP

DR planning is not your full-time job, so it can’t be a resource- and time-intensive process.

DR must be integrated with day-to-day incident management to ensure service continuity

When a tornado takes out your data center, it’s an obvious DR scenario and the escalation towards declaring a disaster is straightforward.

The challenge is to be just as decisive in less-obvious (and more common) DR scenarios such as a critical system hardware/software failure, and knowing when to move from incident management to DR. Don’t get stuck troubleshooting for days when you could have failed over in hours.

Bridge the gap with clearly-defined escalation rules and criteria for when to treat an incident as a disaster.

Source: Info-Tech Research Group; N=92

Myth busted: The DRP is separate from day-to-day ops and incident management.

The most common threats to service continuity are hardware and software failures, network outages, and power outages

Source: Info-Tech Research Group; N=87

Info-Tech Insight

Does this mean I don’t need to worry about natural disasters? No. It means DR planning needs to focus on overall service continuity, not just major disasters. If you ignore the more common but less dramatic causes of service interruptions, you are diminishing the business value of a DRP.

Myth busted: DRPs are just for destructive events – fires, floods, and natural disasters.

DR isn’t about identifying risks; it’s about ensuring service continuity

The traditional approach to DR starts with an in-depth exercise to identify risks to IT service continuity and the probability that those risks will occur.

Here’s why starting with a risk register is ineffective:

• Odds are, you won’t think of every incident that might occur. If you think of twenty risks, it’ll be the twenty-first that gets you. If you try to guard against that twenty-first risk, you can quickly get into cartoonish scenarios and much more costly solutions.
• The ability to failover to another site mitigates the risk of most (if not all) incidents (fire, flood, hardware failure, tornado, etc.). A risk and probability analysis doesn’t change the need for a plan that includes a failover procedure.

Where risk is incorporated in this methodology:

• Use known risks to further refine your strategy (e.g. if you are prone to hurricanes, plan for greater geographic separation between sites; ensure you have backups, in addition to replication, to mitigate the risk of ransomware).
• Identify risks to your ability to execute DR (e.g. lack of cross-training, backups that are not tested) and take steps to mitigate those risks.

Myth busted: A risk register is the critical first step to creating an effective DR plan.

You can’t outsource accountability and you can’t assume your vendor’s DR capabilities meet your needs

Outsourcing infrastructure services – to a cloud provider, co-location provider, or managed service provider (MSP) – can improve your DR and service continuity capabilities. For example, a large public cloud provider will generally have:

• Redundant telecoms service providers, network infrastructure, power feeds, and standby power.
• Round-the-clock infrastructure and security monitoring.
• Multiple data centers in a given region, and options to replicate data and services across regions.

Still, failure is inevitable – it’s been demonstrated multiple times1 through high-profile outages. When you surrender direct control of the systems themselves, it’s your responsibility to ensure the vendor can meet your DR requirements, including:

• A DR site and acceptable recovery times for systems at that site.
• An acceptable replication/backup schedule.

Sources: Kyle York, 2016; Shaun Nichols, 2017; Stephen Burke, 2017

Myth busted: I outsource infrastructure services so I don’t have to worry about DR. That’s my vendor’s responsibility.

Choose flowcharts over process guides, checklists over procedures, and diagrams over descriptions

IT DR is not an airplane disaster movie. You aren’t going to ask a business user to execute a system recovery, just like you wouldn’t really want a passenger with no flying experience to land a plane.

In reality, you write a DR plan for knowledgeable technical staff, which allows you to summarize key details your staff already know. Concise, visual documentation is:

• Quicker to create.
• Easier to use.
• Simpler to maintain.

"Without question, 300-page DRPs are not effective. I mean, auditors love them because of the detail, but give me a 10-page DRP with contact lists, process flows, diagrams, and recovery checklists that are easy to follow."

– Bernard Jones, MBCI, CBCP, CORP, Manager Disaster Recovery/BCP, ActiveHealth Management

Source: Info-Tech Research Group; N=95

*DR Success is based on stated ability to meet recovery time objectives (RTOs) and recovery point objectives (RPOs), and reported confidence in ability to consistently meet targets.

Myth busted: A DRP must include every detail so anyone can execute recovery.

A DRP is part of an overall business continuity plan

A DRP is the set of procedures and supporting documentation that enables an organization to restore its core IT services (i.e. applications and infrastructure) as part of an overall business continuity plan (BCP), as described below. Use the templates, tools, and activities in this blueprint to create your DRP.

Note: For DRP, we focus on business-facing IT services (as opposed to the underlying infrastructure), and then identify required infrastructure as dependencies (e.g. servers, databases, network).

Take a practical but structured approach to creating a concise and effective DRP

Info-Tech offers various levels of support to best suit your needs

DIY Toolkit

"Our team has already made this critical project a priority, and we have the time and capability, but some guidance along the way would be helpful."

Guided Implementation

“Our team knows that we need to fix a process, but we need assistance to determine where to focus. Some check-ins along the way would help keep us on track.”

Workshop

“We need to hit the ground running and get this project kicked off immediately. Our team has the ability to take this over once we get a framework and strategy in place.”

Consulting

“Our team does not have the time or the knowledge to take this project on. We need assistance through the entirety of this project.”

Diagnostics and consistent frameworks used throughout all four options

Info-Tech advisory services deliver measurable value

Info-Tech members save an average of $22,983 and 22 days by working with an Info-Tech analyst on DRP (based on client response data from Info-Tech Research Group’s Measured Value Survey, following analyst advisory on this blueprint).

Why do members report value from analyst engagement?

1. Expert advice on your specific situation to overcome obstacles and speed bumps.
2. Structured project and guidance to stay on track.
3. Project deliverables review to ensure the process is applied properly.

Guided implementation overview

Your trusted advisor is just a call away.

Define DRP scope (Call 1)

Scope requirements, objectives, and your specific challenges. Identify applications/ systems to focus on first.

Define current status and system dependencies (Calls 2-3)

Assess current DRP maturity. Identify system dependencies.

Conduct a BIA (Calls 4-6)

Create an impact scoring scale and conduct a BIA. Identify RTO and RPO for each system.

Recovery workflow (Calls 7-8)

Create a recovery workflow based on tabletop planning. Identify gaps in recovery capabilities.

Projects and action items (Calls 9-10)

Identify and prioritize improvements. Summarize results and plan next steps.

Your guided implementations will pair you with an advisor from our analyst team for the duration of your DRP project.

Workshop overview

Contact your account representative or email Workshops@InfoTech.com for more information.

End-user complaints distract from serious IT-based risks to business continuity

Case Study

Industry: Manufacturing
Source: Info-Tech Research Group Client Engagement

A global manufacturer with annual sales over $1B worked with Info-Tech to improve DR capabilities.

DRP BIA

Conversations with the IT team and business units identified the following impact of downtime over 24 hours:

• Email: Direct Cost: $100k; Goodwill Impact Score: 8.5/16
• ERP: Direct Cost: $1.35mm; Goodwill Impact Score: 12.5/16

Tabletop Testing and Recovery Capabilities

Reviewing the organization’s current systems recovery workflow identified the following capabilities:

• Email: RTO: minutes, RPO: minutes
• ERP: RTO: 14 hours, RPO: 24 hours

Findings

Because of end-user complaints, IT had invested heavily in email resiliency though email downtime had a relatively minimal impact on the business. After working through the methodology, it was clear that the business needed to provide additional support for critical systems.

Insights at each step:

Identify DR Maturity and System Dependencies

Conduct a BIA

Outline Incident Response and Recovery Workflow With Tabletop Exercises

Mitigate Gaps and Risks

Create a Right-Sized Disaster Recovery Plan

Phase 1

Define DRP Scope, Current Status, and Dependencies

Step 1.1: Set Scope, Kick-Off the DRP Project, and Create a Charter

This step will walk you through the following activities:

• Establish a team for DR planning.
• Retrieve and review existing, relevant documentation.
• Create a project charter.

This step involves the following participants:

• DRP Coordinator
• DRP Team (Key IT SMEs)
• IT Managers

Results and Insights

• Set scope for the first iteration of the DRP methodology.
• Don’t try to complete your DR and BCPs all at once.
• Don’t bite off too much at once.

Kick-off your DRP project

You’re ready to start your DR project.

This could be an annual review – but more likely, this is the first time you’ve reviewed the DR plan in years.* Maybe a failed audit might have provided a mandate for DR planning, or a real disaster might have highlighted gaps in DR capabilities. First, set appropriate expectations for what the project is and isn’t, in terms of scope, outputs, and resource commitments. Very few organizations can afford to hire a full-time DR planner, so it’s likely this won’t be your full-time job. Set objectives and timelines accordingly.

Gather a team

• Often, DR efforts are led by the infrastructure and operations leader. This person can act as the DRP coordinator or may delegate this role.
• Key infrastructure subject-matter experts (SMEs) are usually part of the team and involved through the project.

Find and review existing documentation

• An existing DRP may have information you can re-purpose rather than re-create.
• High-level architecture diagrams and network diagrams can help set scope (and will become part of your DR kit).
• Current business-centric continuity of operations plans (COOPs) or BCPs are important to understand.

Set specific, realistic objectives

• Create a project charter (see next slide) to record objectives, timelines, and assumptions.

*Only 20% of respondents to an Info-Tech Research Group survey (N=165) had a complete DRP; only 38% of respondents with a complete or mostly complete DRP felt it would be effective in a crisis.

List DRP drivers and challenges

1(a) Drivers and roadblocks

Estimated Time: 30 minutes

Identify the drivers and challenges to completing a functional DRP plan with the core DR team.

DRP Drivers

• Past outages (be specific):
  • Hardware and software failures
  • External network and power outages
  • Building damage
  • Natural disaster(s)
• Audit findings
• Events in the news
• Other?

DRP Challenges

• Lack of time
• Insufficient DR budget
• Lack of executive support
• No internal DRP expertise
• Challenges making the case for DRP
• Other?

Write down insights from the meeting on flip-chart paper or a whiteboard and use the findings to inform your DRP project (e.g. challenges to address).

Clarify expectations with a project charter

1(b) DRP Project Charter Template

DRP Project Charter Template components:

Define project parameters, roles, and objectives, and clarify expectations with the executive team. Specific subsections are listed below and described in more detail in the remainder of this phase.

• Project Overview: Includes objectives, deliverables, and scope. Leverage relevant notes from the “Project Drivers” brainstorming exercise (e.g. past outages and near misses which help make the case).
• Governance and Management: Includes roles, responsibilities, and resource requirements.
• Project Risks, Assumptions, and Constraints: Includes risks and mitigation strategies, as well as any assumptions and constraints.
• Project Sign-Off: Includes IT and executive sign-off (if required).

Note: Identify the initial team roles and responsibilities first so they can assist in defining the project charter.

Step 1.2: Assess Current State DRP Maturity

This step will walk you through the following activities:

• Complete Info-Tech’s DRP Maturity Scorecard.

This step involves the following participants:

• DRP Coordinator
• IT SMEs

Results and Insights

• Identify the current state of the organization’s DRP and continuity management. Set a baseline for improvement.
• Discover where improvement is most needed to create an effective plan.

Only 38% of IT departments believe their DRPs would be effective in a real crisis

Even organizations with documented DRPs struggle to make them actionable.

• Even when a DRP does become a priority (e.g. due to regulatory or customer drivers), the challenge is knowing where to start and having a methodical step-by-step process for doing the work. With no guide to plan and resource the project, it becomes work that you complete piecemeal when you aren’t working on other projects, or at night after the kids go to bed.
• Far too many organizations create a document to satisfy auditors rather than creating a usable plan. People in this group often just want a fill-in-the-blanks template. What they will typically find is a template for the traditional 300-page manual that goes in a binder that sits on a shelf, is difficult to maintain, and is not effective in a crisis.

Use the DRP Maturity Scorecard to assess the current state of your DRP and identify areas to improve

1(c) DRP Maturity Scorecard

Info-Tech’s DRP Maturity Scorecard evaluates completion status and process maturity for a comprehensive yet practical assessment across three aspects of an effective DRP program – Defining Requirements, Implementation, and Maintenance.

Completion Status: Reflects the progress made with each component of your DRP Program.

Process Maturity: Reflects the consistency and quality of the steps executed to achieve your completion status.

DRP Maturity Assessment: Each component (e.g. BIA) of your DRP Program is evaluated based on completion status and process maturity to provide an accurate holistic assessment. For example, if your BIA completion status is 4 out of 5, but process maturity is a 2, then requirements were not derived from a consistent defined process. The risk is inconsistent application prioritization and misalignment with actual business requirements.

Step 1.3: Identify Applications, Systems, and Dependencies

This step will walk you through the following activities:

• Identify systems, applications, and services, and the business units that use them.
• Document applications, systems, and their dependencies in the DRP Business Impact Analysis Tool.

This step involves the following participants:

• DRP Coordinator
• DRP Team

Results and Insights

• Identify core services and the applications that depend on them.
• Add applications and dependencies to the DRP Business Impact Analysis Tool.

Select 5-10 services to get started on the DRP methodology

1(d) High-level prioritization

Estimated Time: 30 minutes

Working through the planning process the first time can be challenging. If losing momentum is a concern, limit the BIA to a few critical systems to start.

Run this exercise if you need a structured exercise to decide where to focus first and identify the business users you should ask for input on the impact of system downtime.

1. On a whiteboard or flip-chart paper, list business units in a column on the left. List key applications/systems in a row at the top. Draw a grid.
2. At a high level, review how applications are used by each unit. Take notes to keep track of any assumptions you make.
   • Add a ✓ if members of the unit use the application or system.
   • Add an ✱ if members of the unit are heavy users of the application or system and/or use it for time sensitive tasks.
   • Leave the box blank if the app isn’t used by this unit.
3. Use the chart to prioritize systems to include in the BIA (e.g. systems marked with an *) but also include a few less-critical systems to illustrate DRP requirements for a range of systems.

Draw a high-level sketch of your environment

1(e) Sketch your environment

Estimated Time: 1-2 hours

A high-level topology or architectural diagram is an effective way to identify dependencies, application ownership, outsourced services, hardware redundancies, and more.

Note:

• Network diagrams or high-level architecture diagrams help to identify dependencies and redundancies. Even a rough sketch is a useful reference tool for participants, and will be valuable documentation in the final DR plan.
• Keep the drawings tidy. Visualize the final diagram before you start to draw on the whiteboard to help with spacing and placement.
• Collaborate with relevant SMEs to identify dependencies. Keep the drawing high-level.
• Illustrate connections between applications or components with lines. Use color coding to illustrate where applications are hosted (e.g. in-house, at a co-lo, in a cloud or MSP environment).

Document systems and dependencies

Collaborate with system SMEs to identify dependencies for each application or system. Document the dependencies in the DRP Business Impact Analysis Tool (see image below)

• When listing applications, focus on business-facing systems or services that business users will recognize and use terminology they’ll understand.
• Group infrastructure components that support all other services as a single core infrastructure service to simplify dependency mapping (e.g. core router, virtual hosts, ID management, and DNS).
• In general, each data center will have its own core infrastructure components. List each data center separately – especially if different services are hosted at each data center.
• Be specific when documenting dependencies. Use existing asset tracking tables, discovery tools, asset management records, or configuration management tools to identify specific server names.
• Core infrastructure dependencies, such as the network infrastructure, power supply, and centralized storage, will be a common set of dependencies for most applications, so group these into a separate category called “Core Infrastructure” to minimize repetition in your DR planning.
• Document production components in the BIA tool. Capture in-production, redundant components performing the same work on a single dependency line. List standby systems in the notes.

Info-Tech Best Practice

In general, visual documentation is easier to use in a crisis and easier to maintain over time. Use Info-Tech’s research to help build your own visual SOPs.

Document systems and dependencies

1(f) DRP Business Impact Analysis Tool – Record systems and dependencies

Stories from the field: Info-Tech clients find value in Phase 1 in the following ways

An organization uncovers a key dependency that needed to be treated as a Tier 1 system

Reviewing the entire ecosystem for applications identified key dependencies that were previously considered non-critical. For example, a system used to facilitate secure data transfers was identified as a key dependency for payroll and other critical business processes, and elevated to Tier 1.

A picture’s worth a thousand words (and 1600 servers)

Drawing a simple architectural diagram was an invaluable tool to identify key dependencies and critical systems, and to understand how systems and dependencies were interconnected. The drawing was an aha moment for IT and business stakeholders trying to make sense of their 1600-server environment.

Make the case for DRP

A member of the S&P 500 used Info-Tech’s DRP Maturity Scorecard to provide a reliable objective assessment and make the case for improvements to the board of directors.

State government agency initiates a DRP project to complement an existing COOP

Info-Tech's DRP Project Charter enabled the CIO to clarify their DRP project scope and where it fit into their overall COOP. The project charter example provided much of the standard copy – objectives, scope, project roles, methodology, etc. – required to outline the project.

Phase 1: Insights and accomplishments

Created a charter and identified current maturity

Identified systems and dependencies for the BIA

Summary of Accomplishments:

• Created a DRP project charter.
• Completed the DRP Maturity Scorecard and identified current DRP maturity.
• Prioritized applications/systems for a first pass through DR planning.
• Identified dependencies for each application and system.

Up Next: Conduct a BIA to establish recovery requirements

Create a Right-Sized Disaster Recovery Plan

Phase 2

Conduct a BIA to Determine Acceptable RTOs and RPOs

Step 2.1: Define an Objective Impact Scoring Scale

This step will walk you through the following activities:

• Create a scoring scale to measure the business impact of application and system downtime.

This step involves the following participants:

• DRP Coordinator
• DRP Team

Results and Insights

• Use a scoring scale tied to multiple categories of real business impact to develop a more objective assessment of application and system criticality.

Align capabilities to appropriate and acceptable RTOs and RPOs with a BIA

Too many organizations avoid a BIA because they perceive it as onerous or unneeded. A well-managed BIA is straightforward and the benefits are tangible.

A BIA enables you to identify appropriate spend levels, maintain executive support, and prioritize DR planning for a more successful outcome. Info-Tech has found that a BIA has a measurable impact on the organization’s ability to set appropriate objectives and investment goals.

Info-Tech Insight

Business input is important, but don’t let a lack of it delay a draft BIA. Complete a draft based on your knowledge of the business. Create a draft within IT, and use it to get input from business leaders. It’s easier to edit estimates than to start from scratch; even weak estimates are far better than a blank sheet.

Pick impact categories that are relevant to your business to develop a holistic view of business impact

Direct Cost Impact Categories

• Revenue: permanently lost revenue.
  • Example: one third of daily sales are lost due to a website failure.
• Productivity: lost productivity.
  • Example: finance staff can’t work without the accounting system.
• Operating costs: additional operating costs.
  • Example: temporary staff are needed to re-key data.
• Financial penalties: fines/penalties that could be incurred due to downtime.
  • Example: failure to meet contractual service-level agreements (SLAs) for uptime results in financial penalties.

Goodwill, Compliance, and Health and Safety Categories

• Stakeholder goodwill: lost customer, staff, or business partner goodwill due to harm, frustration, etc.
  • Example: customers can’t access needed services because the website is down.
  • Example: a payroll system outage delays paychecks for all staff.
  • Example: suppliers are paid late because the purchasing system is down.
• Compliance, health, and safety:
  • Example: financial system downtime results in a missed tax filing.
  • Example: network downtime disconnects security cameras.

Info-Tech Insight

You don’t have to include every impact category in your BIA. Include categories that could affect your business. Defer or exclude other categories. For example, the bulk of revenue for governmental organizations comes from taxes, which won’t be permanently lost if IT systems fail.

Modify scoring criteria to help you measure the impact of downtime

The scoring scales define different types of business impact (e.g. costs, lost goodwill) using a common four-point scale and 24-hour timeframe to simplify BIA exercises and documentation.

Use the suggestions below as a guide as you modify scoring criteria in the DRP Business Impact Analysis Tool:

• All the direct cost categories (revenue, productivity, operating costs, financial penalties) require the user to define only a maximum value; the tool will populate the rest of the criteria for that category. Use the suggestions below to find the maximum scores for each of the direct cost categories:
  • Revenue: Divide total revenue for the previous year by 365 to estimate daily revenue. Assume this is the most revenue you could lose in a day, and use this number as the top score.
  • Loss of Productivity: Divide fully-loaded labor costs for the organization by 365 to estimate daily productivity costs. Use this as a proxy measure for the work lost if all business stopped for one day.
  • Increased Operating Costs: Isolate this to known additional costs that result from a disruption (e.g. costs for overtime or temporary staff). Estimate the maximum cost for the organization.
  • Financial Penalties: Isolate this to known financial penalties (e.g. due to failure to meet SLAs or compliance requirements). Use the estimated maximum penalty as the highest value on the scale.
• Impact on Goodwill: Use an estimate of the percentage of all stakeholders impacted to assess goodwill impact.
• Impact on Compliance; Impact on Health and Safety: The BIA tool contains default scoring criteria that account for the severity of the impact, the likelihood of occurrence, and in the case of compliance, whether a grace period is available. Use this scale as-is, or adapt this scale to suit your needs.

Modify the default scoring scale in the DRP Business Impact Analysis Tool to reflect your organization

2(a) DRP Business Impact Analysis Tool – Scoring criteria

Step 2.2: Estimate the Impact of Downtime

This step will walk you through the following activities:

• Identify the business impact of service/system/application downtime.

This step involves the following participants:

• DRP Coordinator
• DRP Team
• IT Service SMEs
• Business-Side Technology Owners (optional)

Results and Insights

• Apply the scoring scale to develop a more objective assessment of the business impact of downtime.
• Create criticality tiers based on the business impact of downtime.

Estimate the impact of downtime for each system and application

2(b) Estimate the impact of systems downtime

Estimated Time: 3 hours

On tab 3 of the DRP Business Impact Analysis Tool indicate the costs of downtime, as described below:

1. Have a copy of the “Scoring Criteria” tab available to use as a reference (e.g. printed or on a second display). In tab 3 use the drop-down menu to assign a score of 0 to 4 based on levels of impact defined in the “Scoring Criteria” tab.
2. Work horizontally across all categories for a single system or application. This will familiarize you with your scoring scales for all impact categories, and allow you to modify the scoring scales if needed before you proceed much further.

For example, if a core call center phone system was down:

• Loss of Revenue would be the portion of sales revenue generated through the call center. This might score a 1 or 2 depending on the percent of sales that are processed by the call center.
• The Impact on Customers might be a 2 or 3 depending on the extent that some customers might be using the call center to receive support or purchase new products or services.
• The Legal/Regulatory Compliance and Health or Safety Risk might be a 0, as the call center has no impact in either area.

Add impact scores to the DRP Business Impact Analysis Tool

2(c) DRP Business Impact Analysis Tool

Record business reasons and assumptions that drive BIA scores

2(d) DRP BIA Scoring Context Example

Info-Tech suggests that IT leadership and staff identify the impact of downtime first to create a version that you can then validate with relevant business owners. As you work through the BIA as a team, have a notetaker record assumptions you make to help you explain the results and drive business engagement and feedback.

Some common assumptions:

• You can’t schedule a disaster, so Info-Tech suggests you assume the worst possible timing for downtime. Base the impact of downtime on the worst day for a disaster (e.g. year-end close, payroll run).
• Record assumptions made about who and what are impacted by system downtime.
• Record assumptions made about impact severity.
• If you deviate from the scoring scale, or if a particular impact doesn’t fit well into the defined scoring scale, document the exception.

Use Info-Tech’s DRP BIA Scoring Context Example as a note-taking template.

Info-Tech Insight

You can’t build a perfect scoring scale. It’s fine to make reasonable assumptions based on your judgment and knowledge of the business. Just write down your assumptions. If you don’t write them down, you’ll forget how you arrived at that conclusion.

Assign a criticality rating based on total direct and indirect costs of downtime

2(e) DRP Business Impact Analysis Tool – Assign criticality tiers

Once you’ve finished estimating the impact of downtime, use the following rough guideline to create an initial sort of applications into Tiers 1, 2, and 3.

1. In general, sort applications based on the Total Impact on Goodwill, Compliance, and Safety first.
   • An effective tactic for a quick sort: assign a Tier 1 rating where scores are 50% or more of the highest total score, Tier 2 where scores are between 25% and 50%, and Tier 3 where scores are below 25%. Some organizations will also include a Tier 0 for the highest-scoring systems.
   • Then review and validate these scores and assignments.
2. Next, consider the Total Cost of Downtime.
   • The Total Cost is calculated by the tool based on the Scoring Criteria in tab 2 and the impact scores on tab 3.
   • Decide if the total cost impact justifies increasing the criticality rating (e.g. from Tier 2 to Tier 1 due to high cost impact).
3. Review the assigned impact scores and tiers to check that they’re in alignment. If you need to make an exception, document why. Keep exceptions to a minimum.

Example: Highest total score is 12

Step 2.3: Determine Acceptable RTO/RPO Targets

This step will walk you through the following activities:

• Review the “Debate Space” approach to setting RTO and RPO (recovery targets).
• Set preliminary RTOs and RPOs by criticality tier.

This step involves the following participants:

• DRP Coordinator
• DRP Team

Results and Insights

• Align recovery targets with the business impact of downtime and data loss.

Use the “Debate Space” approach to align RTOs and RPOs with the impact of downtime

The business must validate acceptable and appropriate RTOs and RPOs, but IT can use the guidelines below to set an initial estimate.

Right-size recovery.

A shorter RTO typically requires higher investment. If a short period of downtime has minimal impact, setting a low RTO may not be justifiable. As downtime continues, impact begins to increase exponentially to a point where downtime is intolerable – an acceptable RTO must be shorter than this. Apply the same thinking to RPOs – how much data loss is unnoticeable? How much is intolerable?

The “Debate Space” is between minimal impact and maximum tolerance for downtime.

Estimate appropriate, acceptable RTOs and RPOs for each tier

2(f) Set recovery targets

Estimated Time: 30 minutes

RTO and RPO tiers simplify management by setting similar recovery goals for systems and applications with similar criticality.

Use the “Debate Space” approach to set appropriate and acceptable targets.

1. For RTO, establish a recovery time range that is appropriate based on impact.
   • Overall, the RTO tiers might be 0-4 hours for gold, 4-24 hours for silver, and 24-48 hours for bronze.
2. RPOs reflect target data protection measures.
   • Identify the lowest RPO within a tier and make that the standard.
   • For example, RPO for gold data might be five minutes, silver might be four hours, and bronze might be one day.
   • Use this as a guideline. RPO doesn’t always align perfectly with RTO tiers.
3. Review RTOs and RPOs and make sure they accurately reflect criticality.

Info-Tech Insight

In general, the more critical the system, the shorter the RPO. But that’s not always the case. For example, a service bus might be Tier 1, but if it doesn’t store any data, RPO might be longer than other Tier 1 systems. Some systems may have a different RPO than most other systems in that tier. As long as the targets are acceptable to the business and appropriate given the impact, that’s okay.

Add recovery targets to the DRP Business Impact Analysis Tool

2(g) DRP Business Impact Analysis Tool – Document recovery objectives

Stories from the field: Info-Tech clients find value in Phase 2 in the following ways

Most organizations discover something new about key applications, or the way stakeholders use them, when they work through the BIA and review the results with stakeholders. For example:

Why complete a BIA? There could be a million reasons

• A global manufacturer completed the DRP BIA exercise. When email went down, Service Desk phones lit up until it was resolved. That grief led to a high availability implementation for email. However, the BIA illustrated that ERP downtime was far more impactful.
• ERP downtime would stop production lines, delay customer orders, and ultimately cost the business a million dollars a day.
• The BIA results clearly showed that the ERP needed to be prioritized higher, and required business support for investment.

Move from airing grievances to making informed decisions

The DRP Business Impact Analysis Tool helped structure stakeholder consultations on DR requirements for a large university IT department. Past consultations had become an airing of grievances. Using objective impact scores helped stakeholders stay focused and make informed decisions around appropriate RTOs and RPOs.

Phase 2: Insights and accomplishments

Estimated the business impact of downtime

Set recovery targets

Summary of Accomplishments

• Created a scoring scale tied to different categories of business impact.
• Applied the scoring scale to estimate the business impact of system downtime.
• Identified appropriate, acceptable RTOs and RPOs.

Up Next:Conduct a tabletop planning exercise to establish current recovery capabilities

Create a Right-Sized Disaster Recovery Plan

Phase 3

Identify and Address Gaps in the Recovery Workflow

Step 3.1: Determine Current Recovery Workflow

This step will walk you through the following activities:

• Run a tabletop exercise.
• Outline the steps for the initial response (notification, assessment, disaster declaration) and systems recovery (i.e. document your recovery workflow).
• Identify any gaps and risks in your initial response and systems recovery.

This step involves the following participants:

• DRP Coordinator
• IT Infrastructure SMEs (for systems in scope)
• Application SMEs (for systems in scope)

Results and Insights

• Use a repeatable practical exercise to outline and document the steps you would use to recover systems in the event of a disaster, as well as identify gaps and risks to address.
• This is also a knowledge-sharing opportunity for your team, and a practical means to get their insights, suggestions, and recovery knowledge down on paper.

Tabletop planning: an effective way to test and document your recovery workflow

In a tabletop planning exercise, the DRP team walks through a disaster scenario to map out what should happen at each stage, and effectively defines a high-level incident response plan (i.e. recovery workflow).

Tabletop planning had the greatest impact on meeting recovery objectives (RTOs/RPOs) among survey respondents.

*Note: Relative importance indicates the contribution an individual testing methodology, conducted at least annually, had on predicting success meeting recovery objectives, when controlling for all other types of tests in a regression model. The relative-importance values have been standardized to sum to 100%.

Success was based on the following items:

• RTOs are consistently met.
• IT has confidence in the ongoing ability to meet RTOs.
• RPOs are consistently met.
• IT has confidence in the ongoing ability to meet RPOs.

Why is tabletop planning so effective?

• It enables you to play out a wider range of scenarios than technology-based testing (e.g. full-scale, parallel) due to cost and complexity factors.
• It is non-intrusive, so it can be executed more frequently than other testing methodologies.
• It easily translates into the backbone of your recovery documentation, as it allows you to review all aspects of your recovery plan.

Focus first on IT DR

Your DRP is IT contingency planning. It is not crisis management or BCP.

The goal is to define a plan to restore applications and systems following a disruption. For your first tabletop exercise, Info-Tech recommends you use a non-life-threatening scenario that requires at least a temporary relocation of your data center (i.e. failing over to a DR site/environment). Assume a gas leak or burst water pipe renders the data center inaccessible. Power is shut off and IT must failover systems to another location. Once you create the master procedure, review the plan to ensure it addresses other scenarios.

Info-Tech Insight

When systems fail, you are faced with two high-level options: failover or recover in place. If you document the plan to failover systems to another location, you’ll have documented the core of your DR procedures. This differs from traditional scenario planning where you define separate plans for different what-if scenarios. The goal is one plan that can be adapted to different scenarios, which reduces the effort to build and maintain your DRP.

Conduct a tabletop planning exercise to outline DR procedures in your current environment

3(a) Tabletop planning

Estimated Time: 2-3 hours

For each high-level recovery step, do the following:

1. On white cue cards:
   • Record the step.
   • Indicate the task owner (if required for clarity).
   • Note time required to complete the step. After the exercise, use this to build a running recovery time where 00:00 is when the incident occurred.
2. On yellow cue cards, document gaps in people, process, and technology requirements to complete the step.
3. On red cue cards, indicate risks (e.g. no backup person for a key staff member).

Do:

• Review the complete workflow from notification all the way to user acceptance testing.
• Keep focused; stay on task and on time.
• Revisit each step and record gaps and risks (and known solutions, but don’t dwell on this).
• Revise and improve the plan with task owners.

Don't:

• Get weighed down by tools.
• Document the details right away – stick to the high-level plan for the first exercise.
• Try to find solutions to every gap/risk as you go. Save in-depth research/discussion for later.

Flowchart the current-state incident response plan (i.e. document the recovery workflow)

3(b) DRP Recovery Workflow Template and Case Study: Practical, Right-Sized DRP

Why use flowcharts?

• Flowcharts provide an at-a-glance view, ideal for disaster scenarios where pressure is high and quick upward communication is necessary.
• For experienced staff, a high-level reminder of key steps is sufficient.

Use the completed tabletop planning exercise results to build this workflow.

"We use flowcharts for our declaration procedures. Flowcharts are more effective when you have to explain status and next steps to upper management." – Assistant Director, IT Operations, Healthcare Industry

Source: Info-Tech Research Group Interview

For a formatted template you can use to capture your plan, see Info-Tech’s DRP Recovery Workflow Template.

For a completed example of tabletop planning results, review Info-Tech’s Case Study: Practical, Right-Sized DRP.

Identify RPA

What’s my RPA? Consider the following case:

• Once a week, a full backup is taken of the complete ERP system and is transferred over the WAN to a secondary site 250 miles away, where it is stored on disk.
• Overnight, an incremental backup is taken of the day’s changes, and is transferred to the same secondary site, and also stored on disk.
• During office hours, the SAN takes a snapshot of changes which are kept on local storage (information on the accounting system usually only changes during office hours).
• So what’s the RPA? One hour (snapshots), one day (incrementals), or one week (full backups)?

When identifying RPA, remember the following:

You are planning for a disaster scenario, where on-site systems may be inaccessible and any copies of data taken during the disaster may fail, be corrupt, or never make it out of the data center (e.g. if the network fails before the backup file ships). In the scenario above, it seems likely that off-site incremental backups could be restored, leading to a 24-hour RPA. However, if there were serious concerns about the reliability of the daily incrementals, the RPA could arguably be based on the weekly full backups.

Info-Tech Best Practice

The RPA is a commitment to the maximum data you would lose in a DR scenario with current capabilities (people, process, and technology). Pick a number you can likely achieve. List any situations where you couldn’t meet this RPA, and identify those for a risk tolerance discussion. In the example above, complete loss of the primary SAN would also mean losing the snapshots, so the last good copy of the data could be up to 24-hours old.

Add recovery actuals (RTA/RPA) to your copy of the BIA

3(c) DRP Business Impact Analysis Tool– Recovery actuals

On the “Impact Analysis” tab in the DRP Business Impact Analysis Tool, enter the estimated maximum downtime and data loss in the RTA and RPA columns.

1. Estimate the RTA based on the required time for complete recovery. Review your recovery workflow to identify this timeline. For example, if the notification, assessment, and declaration process takes two hours, and systems recovery requires most of a day, the estimated RTA could be 24 hours.
2. Estimate the RPA based on the longest interval between copies of the data being shipped offsite. For example, if data on a particular system is backed up offsite once per day, and the onsite system was destroyed just before that backup began, the entire day’s data could be lost and estimated RPA could be 24 hours. Note: Enter 9999 to indicate that data is unrecoverable.

Info-Tech Best Practice

It’s okay to round numbers to the nearest shift, day, or week for simplicity (e.g. 24 hours rather than 22.5 hours, or 8 hours rather than 7.25 hours).

Test the recovery workflow against additional scenarios

3(d) Workflow review

Estimated Time: 1 hour

Review your recovery workflow with a different scenario in mind.

• Work from and update the soft copy of your recovery workflow.
• Would any steps be different if the scenario changes? If yes, capture the different flow with a decision diamond. Identify any new gaps or risks you encounter with red and yellow cards. Use as few decision diamonds as possible.

Info-Tech Best Practice

As you start to consider scenarios where injuries or loss of life are a possibility, remember that health and safety risks are the top priority in a crisis. If there’s a fire in the data center, evacuating the building is the first priority, even if that means foregoing a graceful shut down. For more details on emergency response and crisis management, see Implement Crisis Management Best Practices.

Consider additional IT disaster scenarios

3(e) Thought experiment – Review additional scenarios

Walk through your recovery workflow in the context of additional, different scenarios to ensure there are no gaps. Collaborate with your DR team to identify changes that might be required, and incorporate these changes in the plan.

Step 3.2: Identify and Prioritize Projects to Close Gaps

This step will walk you through the following activities:

• Analyze the gaps that were identified from the maturity scorecard, tabletop planning exercise, and the RTO/RPO gaps analysis.
• Brainstorm solutions to close gaps and mitigate risks.
• Determine a course of action to close these gaps. Prioritize each project. Create a project implementation timeline.

This step involves the following participants:

• DRP Coordinator
• IT Infrastructure SMEs

Results and Insights

• Prioritized list of projects and action items that can improve DR capabilities.
• Often low-cost, low-effort quick wins are identified to mitigate at least some gaps/risks. Higher-cost, higher-effort projects can be part of a longer-term IT strategy. Improving service continuity is an ongoing commitment.

Brainstorm solutions to address gaps and risk

3(f) Solutioning

Estimated Time: 1.5 hours

1. Review each of the risk and gap cards from the tabletop exercise.
2. As a group, brainstorm ideas to address gaps, mitigate risks, and improve resiliency. Write the list of ideas on a whiteboard or flip-chart paper. The solutions can range from quick-wins and action items to major capital investments.
3. Try to avoid debates about feasibility at this point – that should happen later. The goal is to get all ideas on the board.

Info-Tech Best Practice

It’s about finding ways to solve the problem, not about solving the problem. When you’re brainstorming solutions to problems, don’t stop with the first idea, even if the solution seems obvious. The first idea isn’t always the best or only solution; other ideas can expand on and improve that first idea.

Select an optimal DR deployment model from a world of choice

There are many options for a DR deployment. What makes sense for you?

• Sifting through the options for a DR site can be overwhelming. Simplify by eliminating deployment models that aren’t a good fit for your requirements or organization using Info-Tech’s research.
• Someone will ask you about DR in the cloud. Cut to the chase and evaluate cloud for fit with your organization’s current capabilities and requirements. Read about the 10 Secrets for Successful DR in the Cloud.
• Selecting and deploying a DR site is an exercise in risk mitigation. IT’s role is to advise the business on options to address the risk of not having a DR site, including cost and effort estimates. The business must then decide how to manage risk. Build total cost of ownership (TCO) estimates and evaluate possible challenges and risks for each option.

Is it practical to invest in greater geo-redundancy that meets RTOs and RPOs during a widespread event?

Info-Tech suggests you consider events that impact both sites, and your risk tolerance for that impact. Outline the impact of downtime at a high level if both the primary and secondary site were affected. Research how often events severe enough to have impacted both your primary and secondary sites have occurred in the past. What’s the business tolerance for this type of event?

A common strategy: have a primary and DR site that are close enough to support low RPO/RTO, but far enough away to mitigate the impact of known regional events. Back up data to a remote third location as protection against a catastrophic event.

Info-Tech Insight

Approach site selection as a project. Leverage Select an Optimal Disaster Recovery Deployment Model to structure your own site-selection project.

Set up the DRP Roadmap Tool

3(g) DRP Roadmap Tool – Set up tool

Use the DRP Roadmap Tool to create a high-level roadmap to plan and communicate DR action items and initiatives. Determine the data you’ll use to define roadmap items.

Plan next steps by estimating timeline, effort, priority, and more

3(h) DRP Roadmap Tool – Describe roadmap items

Review and communicate the DRP Roadmap Tool

3(i) DRP Roadmap Tool – View roadmap chart

Step 3.3: Review the Future State Recovery Process

This step will walk you through the following activities:

• Update the recovery workflow to outline your future recovery procedure.
• Summarize findings from DR exercises and present the results to the project sponsor and other interested executives.

This step involves the following participants:

• DRP Coordinator
• IT SMEs (Future State Recovery Flow)
• DR Project Sponsor

Results and Insights

• Summarize results from DR planning exercises to make the case for needed DR investment.

Outline your future state recovery flow

3(j) Update the recovery workflow to outline response and recovery in the future

Estimated Time: 30 minutes

Outline your expected future state recovery flow to demonstrate improvements once projects and action items have been completed.

1. Create a copy of your DRP recovery workflow in a new tab in Visio.
2. Delete gap and risk cards that are addressed by proposed projects. Consolidate or eliminate steps that would be simplified or streamlined in the future if projects are implemented.
3. Create a short-, medium-, and long-term review of changes to illustrate improvements over time to the project roadmap.
4. Update this workflow as you implement and improve DR capabilities.

Validate recovery targets and communicate actual recovery capabilities

3(k) Validate findings, present recommendations, secure budget

Estimated Time: time required will vary

1. Interview managers or process owners to validate RTO, RPO, and business impact scores.Use your assessment of “heavy users” of particular applications (picture at right) to remind you which business users you should include in the interview process.
2. Present an overview of your findings to the management team.Use Info-Tech’s DRP Recap and Results Template to summarize your findings.
3. Take projects into the budget process.With the management team aware of the rationale for investment in DRP, build the business case and secure budget where needed.

Present DRP findings and make the case for needed investment

3(I) DRP Recap and Results Template

Create a communication deck to recap key findings for stakeholders.

• Write a clear problem statement. Identify why you did this project (what problem you’re solving).
• Clearly state key findings, insights, and recommendations.
• Leverage the completed tools and templates to populate the deck. Callouts throughout the template presentation will direct you to take and populate screenshots throughout the document.
• Use the presentation to communicate key findings to, and gather feedback from, business unit managers, executives, and IT staff.

Stories from the field: Info-Tech clients find value in Phase 3 in the following ways

Tabletop planning is an effective way to discover gaps in recovery capabilities. Identify issues in the tabletop exercise so you can manage them before disaster strikes. For example:

Back up a second…

A client started to back up application data offsite. To minimize data transfer and storage costs, the systems themselves weren’t backed up. Working through the restore process at the DR site, the DBA realized 30 years of COBOL and SQR code – critical business functionality – wasn’t backed up offsite.

Net… work?

A 500-employee professional services firm realized its internet connection could be a significant roadblock to recovery. Without internet, no one at head office could access critical cloud systems. The tabletop exercise identified this recovery bottleneck and helped prioritize the fix on the roadmap.

Someone call a doctor!

Hospitals rely on their phone systems for system downtime procedures. A tabletop exercise with a hospital client highlighted that if the data center were damaged, the phone system would likely be damaged as well. Identifying this provided more urgency to the ongoing VOIP migration.

The test of time

A small municipality relied on a local MSP to perform systems restore, but realized it had never tested the restore procedure to identify RTA. Contacting the MSP to review capabilities became a roadmap item to address this risk.

Phase 3: Insights and accomplishments

Outlined the DRP response and risks to recovery

Brainstormed risk mitigation measures

Summary of Accomplishments

• Planned and documented your DR incident response and systems recovery workflow.
• Identified gaps and risks to recovery and incident management.
• Brainstormed and identified projects and action items to mitigate risks and close gaps.

Up Next: Leverage the core deliverables to complete, extend, and maintain your DRP

Create a Right-Sized Disaster Recovery Plan

Phase 4

Complete, Extend, and Maintain Your DRP

Phase 4: Complete, Extend, and Maintain Your DRP

This phase will walk you through the following activities:

• Identify progress made on your DRP by reassessing your DRP maturity.
• Prioritize the highest value major initiatives to complete, extend, and maintain your DRP.

This phase involves the following participants:

• DRP Coordinator
• Executive Sponsor

Results and Insights

• Communicate the value of your DRP by demonstrating progress against items in the DRP Maturity Scorecard.
• Identify and prioritize future major initiatives to support the DRP, and the larger BCP.

Celebrate accomplishments, plan for the future

Congratulations! You’ve completed the core DRP deliverables and made the case for investment in DR capabilities. Take a moment to celebrate your accomplishments.

This milestone is an opportunity to look back and look forward.

• Look back: measure your progress since you started to build your DRP. Revisit the assessments completed in phase 1, and assess the change in your overall DRP maturity.
• Look forward: prioritize future initiatives to complete, extend, and maintain your DRP. Prioritize initiatives that are the highest impact for the least requirement of effort and resources.

We have completed the core DRP methodology for key systems:

• BIA, recovery objectives, high-level recovery workflow, and recovery actuals.
• Identify key tasks to meet recovery objectives.

What could we do next?

• Repeat the core methodology for additional systems.
• Identify a DR site to meet recovery requirements, and review vendor DR capabilities.
• Create a summary DRP document including requirements, capabilities, and change procedures.
• Create a test plan and detailed recovery documentation.
• Coordinate the creation of BCPs.
• Integrate DR in other key operational processes.

Revisit the DRP Maturity Scorecard to measure progress and identify remaining areas to improve

4(a) DRP Maturity Scorecard – Reassess your DRP program maturity

1. Find the copy of the DRP Maturity Scorecard you completed previously. Save a second copy of the completed scorecard in the same folder.
2. Update scoring where you have improved your DRP documentation or capabilities.
3. Review the new scores on tab 3. Compare the new scores to the original scores.

Info-Tech Best Practice

Use the completed, updated DRP Maturity Scorecard to demonstrate the value of your continuity program, and to help you decide where to focus next.

Prioritize major initiatives to complete, extend, and maintain the DRP

4(b) Prioritize major initiatives

Estimated Time: 2 hours

Prioritize major initiatives that mitigate significant risk with the least cost and effort.

1. Use the scoring criteria below to evaluate risk, effort, and cost for potential initiatives. Modify the criteria if required for your organization. Write this out on a whiteboard or flip-chart paper.
2. Assign a score from 1 to 3. Multiply the scores for each initiative together for an aggregate score. In general, prioritize initiatives with higher scores.

Info-Tech Best Practice

You can use a similar scoring exercise to prioritize and schedule high-benefit, low-effort, low-cost items identified in the roadmap in phase 3.

Example: Prioritize major initiatives

4(b) Prioritize major initiatives continued

Write out the table on a whiteboard (record the results in a spreadsheet for reference). In the case below, IT might decide to work on repeating the core methodology first as they create the active testing plans, and tackle process changes later.

Info-Tech Best Practice

Find a pace that allows you to keep momentum going, but also leaves enough time to act on the initial findings, projects, and action items identified in the DRP Roadmap Tool. Include these initiatives in the Roadmap tool to visualize how identified initiatives fit with other tasks identified to improve your recovery capabilities.

Repeat the core DR methodology for additional systems and applications

You have created a DR plan for your most critical systems. Now, add the rest:

• Build on the work you’ve already done. Re-use the BIA scoring scale. Update your existing recovery workflows, rather than creating and formatting an entirely new document. A number of steps in the recovery will be shared with, or similar to, the recovery procedures for your Tier 1 systems.

Risks and Challenges Mitigated

• DR requirements and capabilities for less-critical systems have not been evaluated.
• Gaps in the recovery process for less critical systems have not been evaluated or addressed.
• DR capabilities for less critical systems may not meet business requirements.

Info-Tech Best Practice

Use this example of a complete, practical, right-size DR plan to drive and guide your efforts.

Extend your core DRP deliverables

You’ve completed the core DRP deliverables. Continue to create DRP documentation to support recovery procedures and governance processes:

• DR documentation efforts fail when organizations try to boil the ocean with an all-in-one plan aimed at auditors, business leaders, and IT. It’s long, hard to maintain, and ends up as shelfware.
• Create documentation in layers to keep it manageable. Build supporting documentation over time to support your high-level recovery workflow.

Risks and Challenges Mitigated

• Key contact information, escalation, and disaster declaration responsibilities are not identified or formalized.
• DRP requirements and capabilities aren’t centralized. Key DRP findings are in multiple documents, complicating governance and oversight by auditors, executives, and board members.
• Detailed recovery procedures and peripheral information (e.g. network diagrams) are not documented.

Info-Tech Best Practice

Use this example of a complete, practical, right-size DR plan to drive and guide your efforts.

Select an optimal DR deployment model and deployment site

Your DR site has been identified as inadequate:

• Begin with the end in mind. Commit to mastering the selected model and leverage your vendor relationship for effective DR.
• Cut to the chase and evaluate the feasibility of cloud first. Gauge your organization’s current capabilities for DR in the cloud before becoming infatuated with the idea.
• A mixed model gives you the best of both worlds. Diversify your strategy by identifying fit for purpose and balancing the work required to maintain various models.

Risks and Challenges Mitigated

• Without an identified DR site, you’ll be scrambling when a disaster hits to find and contract for a location to restore IT services.
• Without systems and application data backed up offsite, you stand to lose critical business data and logic if all copies of the data at your primary site were lost.

Info-Tech Best Practice

Use Info-Tech’s blueprint, Select the Optimal Disaster Recovery Deployment Model, to help you make sense of a world of choice for your DR site.

Extend DRP findings to business process resiliency with a BCP pilot

Integrate your findings from DRP into the overall BCP:

• As an IT leader you have the skillset and organizational knowledge to lead a BCP project, but ultimately business leaders need to own the BCP – they know their processes and requirements to resume business operations better than anyone else.
• The traditional approach to BCP is a massive project that most organizations can’t execute without hiring a consultant. To execute BCP in-house, carve up the task into manageable pieces.

Risks and Challenges Mitigated

• No formal plan exists to recover from a disruption to critical business processes.
• Business requirements for IT systems recovery may change following a comprehensive review of business continuity requirements.
• Outside of core systems recovery, IT could be involved in relocating staff, imaging and issuing new end-user equipment, etc. Identifying these requirements is part of BCP.

Info-Tech Best Practice

Use Info-Tech’s blueprint, Develop a Business Continuity Plan, to develop and deploy a repeatable BCP methodology.

Test the plan to validate capabilities and cross-train staff on recovery procedures

You don’t have a program to regularly test the DR plan:

• Most DR tests are focused solely on the technology and not the DR management process – which is where most plans fail.
• Be proactive – establish an annual test cycle and identify and coordinate resources well in advance.
• Update DRP documentation with findings from the plan, and track the changes you make over time.

Risks and Challenges Mitigated

• Gaps likely still exist in the plan that are hard to find without some form of testing.
• Customers and auditors may ask for some form of DR testing.
• Staff may not be familiar with DR documentation or how they can use it.
• No formal cycle to validate and update the DRP.

Info-Tech Best Practice

Uncover deficiencies in your recovery procedures by using Info-Tech’s blueprint Reduce Costly Downtime Through DR Testing.

“Operationalize” DRP management

Inject DR planning in key operational processes to support plan maintenance:

• Major changes, or multiple routine changes, can materially alter DR capabilities and requirements. It’s not feasible to update the DR plan after every routine change, so leverage criticality tiers in the BIA to focus your change management efforts. Critical systems require more rigorous change procedures.
• Likewise, you can build criticality tiers into more focused project management and performance measurement processes.
• Schedule regular tasks in your ticketing system to verify capabilities and cross-train staff on key recovery procedures (e.g. backup and restore).

Risks and Challenges Mitigated

• DRP is not updated “as needed” – as requirements and capabilities change due to business and technology changes.
• The DRP is disconnected from day-to-day operations.

Review infrastructure service provider DR capabilities

Insert DR planning in key operational processes to support plan maintenance:

• Reviewing vendor DR capabilities is a core IT vendor management competency.
• As your DR requirements change year-to-year, ensure your vendors’ service commitments still meet your DR requirements.
• Identify changes in the vendor’s service offerings and DR capabilities, e.g. higher costs for additional DR support, new offerings to reduce potential downtime, or conversely, a degradation in DR capabilities.

Risks and Challenges Mitigated

• Vendor capabilities haven’t been measured against business requirements.
• No internal capability exists currently to assess vendor ability to meet promised SLAs.
• No internal capability exists to track vendor performance on recoverability.

Phase 4: Insights and accomplishments

Identified progress against targets

Prioritized further initiatives

Added initiatives to the roadmap

Summary of Accomplishments

• Developed a list of high-priority initiatives that can support the extension and maintenance of the DR plan over the long term.
• Reviewed and update maturity assessments to establish progress and communicate the value of the DR program.

Summary of accomplishment

Knowledge Gained

• Conduct a BIA to determine appropriate targets for RTOs and RPOs.
• Identify DR projects required to close RTO/RPO gaps and mitigate risks.
• Use tabletop planning to create and validate an incident response plan.

Processes Optimized

• Your DRP process was optimized, from BIA to documenting an incident response plan.
• Your vendor evaluation process was optimized to identify and assess a vendor’s ability to meet your DR requirements, and to repeat this evaluation on an annual basis.

Deliverables Completed

• DRP Maturity Scorecard
• DRP Business Impact Analysis Tool
• DRP Roadmap Tool
• Incident response plan and systems recovery workflow
• Executive presentation

Info-Tech’s insights bust the most obstinate myths of DRP

Myth #1: DRPs need to focus on major events such as natural disasters and other highly destructive incidents such as fire and flood.

Reality: The most common threats to service continuity are hardware and software failures, network outages, and power outages.

Myth #2: Effective DRPs start with identifying and evaluating potential risks.

Reality: DR isn’t about identifying risks; it’s about ensuring service continuity.

Myth #3: DRPs are separate from day-to-day operations and incident management.

Reality: DR must be integrated with service management to ensure service continuity.

Myth #4: I use a co-lo or cloud services so I don’t have to worry about DR. That’s my vendor’s responsibility.

Reality: You can’t outsource accountability. You can’t just assume your vendor’s DR capabilities will meet your needs.

Myth #5: A DRP must include every detail so anyone can execute the recovery.

Reality: IT DR is not an airplane disaster movie. You aren’t going to ask a business user to execute a system recovery, just like you wouldn’t really want a passenger with no flying experience to land a plane.

Supplement the core documentation with these tools and templates

• An Excel workbook workbook to track key roles on DR, business continuity, and emergency response teams. Can also track DR documentation location and any hardware purchases required for DR.
• A questionnaire template and a response tracking tool to structure your investigation of vendor DR capabilities.
• Integrate escalation with your DR plan by defining incident severity and escalation rules . Use this example as a template or integrate ideas into your own severity definitions and escalation rules in your incident management procedures.
• A minute-by-minute time-tracking tool to capture progress in a DR or testing scenario. Monitor progress against objectives in real time as recovery tasks are started and completed.

Next steps: Related Info-Tech research

Select the Optimal Disaster Recovery Deployment Model Evaluate cloud, co-lo, and on-premises disaster recovery deployment models.

Develop a Business Continuity Plan Streamline the traditional approach to make BCP development manageable and repeatable.

Prepare for a DRP Audit Assess your current DRP maturity, identify required improvements, and complete an audit-ready DRP summary document.

Document and Maintain Your Disaster Recovery Plan Put your DRP on a diet: keep it fit, trim, and ready for action.

Reduce Costly Downtime Through DR Testing Improve your DR plan and your team’s ability to execute on it.

Implement Crisis Management Best Practices An effective crisis response minimizes the impact of a crisis on reputation, profitability, and continuity.

Research contributors and experts

• Alan Byrum, Director of Business Continuity, Intellitech
• Bernard Jones (MBCI, CBCP, CORP, ITILv3), Owner/Principal, B Jones BCP Consulting, LLC
• Paul Beaudry, Assistant Vice-President, Technical Services, MIS, Richardson International Limited
• Yogi Schulz, President, Corvelle Consulting

Glossary

• Business Continuity Management (BCM) Program: Ongoing management and governance process supported by top management and appropriately resourced to implement and maintain business continuity management. (Source: ISO 22301:2012)
• Business Continuity Plan (BCP): Documented procedures that guide organizations to respond, recover, resume, and restore to a pre-defined level of operation following disruption. The BCP is not necessarily one document, but a collection of procedures and information.
• Crisis: A situation with a high level of uncertainty that disrupts the core activities and/or credibility of an organization and requires urgent action. (Source: ISO 22300)
• Crisis Management Team (CMT): A group of individuals responsible for developing and implementing a comprehensive plan for responding to a disruptive incident. The team consists of a core group of decision makers trained in incident management and prepared to respond to any situation.
• Disaster Recovery Planning (DRP): The activities associated with the continuing availability and restoration of the IT infrastructure.
• Incident: An event that has the capacity to lead to loss of, or a disruption to, an organization’s operations, services, or functions – which, if not managed, can escalate into an emergency, crisis, or disaster.

BCI Editor’s Note: In most countries “incident” and “crisis” are used interchangeably, but in the UK the term “crisis” has been generally reserved for dealing with wide-area incidents involving Emergency Services. The BCI prefers the use of “incident” for normal BCM purposes. (Source: The Business Continuity Institute)

• Incident Management Plan: A clearly defined and documented plan of action for use at the time of an incident, typically covering the key personnel, resources, services, and actions needed to implement the incident management process.
• IT Disaster: A service interruption requiring IT to rebuild a service, restore from backups, or activate redundancy at the backup site.
• Recovery Point: Time elapsed between the last good copy of the data being taken and failure/corruption on the production environment; think of this as data loss.
• Recovery Point Actual (RPA): The currently achievable recovery point after a disaster event, given existing people, processes, and technology. This reflects expected maximum data loss that could actually occur in a disaster scenario.
• Recovery Point Objective (RPO): The target recovery point after a disaster event, usually calculated in hours, on a given system, application, or service. Think of this as acceptable and appropriate data loss. RPO should be based on a business impact analysis (BIA) to identify an acceptable and appropriate recovery target.
• Recovery Time: Time required to restore a system, application, or service to a functional state; think of this as downtime.
• Recovery Time Actual (RTA): The currently achievable recovery time after a disaster event, given existing people, processes, and technology. This reflects expected maximum downtime that could actually occur in a disaster scenario.
• Recovery Time Objective (RTO): The target recovery time after a disaster event for a given system, application, or service. RTO should be based on a business impact analysis (BIA) to identify acceptable and appropriate downtime.

Bibliography

BCMpedia. “Recovery Objectives: RTO, RPO, and MTPD.” BCMpedia, n.d. Web.

Burke, Stephen. “Public Cloud Pitfalls: Microsoft Azure Storage Cluster Loses Power, Puts Spotlight On Private, Hybrid Cloud Advantages.” CRN, 16 Mar. 2017. Web.

Elliot, Stephen. “DevOps and the Cost of Downtime: Fortune 1000 Best Practice Metrics Quantified.” IDC, 2015. Web.

FEMA. Planning & Templates. FEMA, 2015. Web.

FINRA. “Business Continuity Plans and Emergency Contact Information.” FINRA, 2015. Web.

FINRA. “FINRA, the SEC and CFTC Issue Joint Advisory on Business Continuity Planning.” FINRA, 2013. Web.

Gosling, Mel, and Andrew Hiles. “Business Continuity Statistics: Where Myth Meets Fact.” Continuity Central, 2009. Web.

Hanwacker, Linda. “COOP Templates for Success Workbook.” The LSH Group, n.d. Web.

Homeland Security. Federal Information Security Management Act (FISMA). Homeland Security, 2015. Web.

Nichols, Shaun. “AWS's S3 Outage Was So Bad Amazon Couldn't Get Into Its Own Dashboard to Warn the World.” The Register, 1 Mar. 2017. Web.

Potter, Patrick. “BCM Regulatory Alphabet Soup.” RSA Archer Organization, 2012. Web.

Rothstein, Philip Jan. “Disaster Recovery Testing: Exercising Your Contingency Plan.” Rothstein Associates Inc., 2007. Web.

The Business Continuity Institute. “The Good Practice Guidelines.” The Business Continuity Institute, 2013. Web.

The Disaster Recovery Journal. “Disaster Resource Guide.” The Disaster Recovery Journal, 2015. Web.

The Disaster Recovery Journal. “DR Rules & Regulations.” The Disaster Recovery Journal, 2015. Web.

The Federal Financial Institution Examination Council (FFIEC). Business Continuity Planning. IT Examination Handbook InfoBase, 2015. Web.

York, Kyle. “Read Dyn’s Statement on the 10/21/2016 DNS DDoS Attack.” Oracle, 22 Oct. 2016. Web.

Harness Configuration Management Superpowers

Create a configuration management practice that will provide ongoing value to the organization.

EXECUTIVE BRIEF

Analyst Perspective

A robust configuration management database (CMDB) can provide value to the business and superpowers to IT. It's time to invest smartly to reap the rewards.

IT environments are becoming more and more complex, and balancing demands for stability and demands for faster change requires visibility to make the right decisions. IT needs to know their environment intimately. They need to understand dependencies and integrations and feel confident they are making decisions with the most current and accurate view.

Solutions for managing operations rely on the CMDB to bring visibility to issues, calculate impact, and use predictive analytics to fix performance issues before they become major incidents. AIOps solutions need accurate data, but they can also help identify configuration drift and flag changes or anomalies that need investigation.

The days of relying entirely on manual entry and updates are all but gone, as the functionality of a robust configuration management system requires daily updates to provide value. We used to rely on that one hero to make sure information was up to date, but with the volume of changes we see in most environments today, it's time to improve the process and provide superpowers to the entire IT department.

Sandi Conrad, ITIL Managing Professional
Principal Research Director, IT Infrastructure & Operations, Info-Tech Research Group

Executive Summary

Your Challenge

• Build a configuration management database (CMDB): You need to implement a CMDB, populate it with records and relationships, and integrate it with discovery and management tools.
• Identify the benefits of a CMDB: Too many CMDB projects fail because IT tries to collect everything. Base your data model on the desired use cases.
• Define roles and responsibilities: Keeping data accurate and updated is difficult. Identify who will be responsible for helping

Common Obstacles

• Significant process maturity is required: Service configuration management (SCM) requires high maturity in change management, IT asset management, and service catalog practices.
• Large investment: Building a CMDB takes a large amount of effort, process, and expertise.
• Tough business case: Configuration management doesn't directly provide value to the business, but it requires a lot of investment from IT.

Info-Tech's Approach

• Define your scope and objectives: Identify the use cases for SCM and prioritize those objectives into phases.
• Design the CMDB data model: Align with your existing configuration management system's data model.
• Operationalize configuration record updates: Integrate your SCM practice with existing practices and lifecycles.

Start small

Scope creep is a serial killer of configuration management databases and service configuration management practices.

Insight summary

Many vendors are taking a CMDB-first approach to enable IT operations or sometimes asset management. It's important to ensure processes are in place immediately to ensure the data doesn't go stale as additional modules and features are activated.

Define processes early to ensure success

The right mindset is just as important as the right tools. By involving everyone early, you can ensure the right data is captured and validated and you can make maintenance part of the culture. This is critical to reaching early and continual value with a CMDB.

Identify use cases

The initial use case will be the driving force behind the first assessment of return on investment (ROI). If ROI can be realized early, momentum will increase, and the team can build on the initial successes.

If you don't see value in the first year, momentum diminishes and it's possible the project will never see value.

Keep the initial scope small and focused

Discovery can collect a lot of data quickly, and it's possible to be completely overwhelmed early in the process.

Build expertise and troubleshoot issues with a smaller scope, then build out the process.

Minimize customizations

Most CMDBs have classes and attributes defined as defaults. Use of the defaults will enable easier implementation and faster time to value, especially where automations and integrations depend on standard terms for field mapping.

Automate as much as possible

In large, complex environments, the data can quickly become unmanageable. Use automation as much as possible for discovery, dependency mapping, validation, and alerts. Minimize the amount of manual work but ensure everyone is aware of where and how these manual updates need to happen to see continual value.

Configuration management will improve functionality of all surrounding processes

A well-functioning CMDB empowers almost all other IT management and governance practices.

Service configuration management is about:

• Building a system of record about IT services and the components that support those services.
• Continuously reconciling and validating information to ensure data accuracy.
• Ensuring the data lifecycle is defined and well understood and can pass data and process audits.
• Accessing information in a variety of ways to effectively serve IT and the business.

Configuration management most closely impacts these practices

Info-Tech Research Group sees a clear relationship.

When an IT department reports they are highly effective at configuration management, they are much more likely to report they are highly effective at these management and governance processes:

The data is clear

Service configuration management is about more than just doing change management more effectively.

Source: Info-Tech Research Group, IT Management and Governance Diagnostic; N=684 organizations, 2019 to July 2022.

Make the case to use configuration management to improve IT operations

Consider the impact of access to data for informing innovations, optimization efforts, and risk assessments.

75% of Uptime's 2021 survey respondents who had an outage in the past three years said the outage would have been prevented if they'd had better management or processes.(1)

It doesn't have to be that way!

Enterprise-grade IT service management (ITSM) tools require a CMDB for the different modules to work together and to enable IT operations management (ITOM), providing greater visibility.

Decisions about changes can be made with accurate data, not guesses.

The CMDB can give the service desk fast access to helpful information about the impacted components, including a history of similar incidents and resolutions and the relationship between the impacted components and other systems and components.

Turn your team into IT superheroes.

CMDB data makes it easier for IT Ops groups to:

• Avoid change collisions.
• Eliminate poor changes due to lack of visibility into complex systems.
• Identify problematic equipment.
• Troubleshoot incidents.
• Expand the services provided by tier 1 and through automation.

Benefits of configuration management

For IT

• Configuration management will supercharge processes that have relied on inherent knowledge of the IT environment to make decisions.
• IT will more quickly analyze and understand issues and will be positioned to improve and automate issue identification and resolution.
• Increase confidence and reduce risks for decisions involving release and change management with access to accurate data, regardless of the complexity of the environment.
• Reduce or eliminate unplanned work related to poor outcomes due to decisions made with incorrect or incomplete data.

For the Business

• Improve strategic planning for business initiatives involving IT solutions, which may include integrations, development, or security concerns.
• More quickly deploy new solutions or updates due to visibility into complex environments.
• Enable business outcomes with reliable and stable IT systems.
• Reduce disruptions caused by planning without accurate data and improve resolution times for service interruptions.
• Improve access to reporting for budgeting, showbacks, and chargebacks as well as performance metrics.

Measure the value of this blueprint

Fast-track your planning and increase the success of a configuration management program with this blueprint

"The workshop was well run, with good facilitation, and gained participation from even the most difficult parts of the audience. The best part of the experience was that if I were to find myself in the same position in the future, I would repeat the workshop."

– University of Exeter

Info-Tech offers various levels of support to best suit your needs

DIY Toolkit

“Our team has already made this critical project a priority, and we have the time and capability, but some guidance along the way would be helpful.”

Guided Implementation

“Our team knows that we need to fix a process, but we need assistance to determine where to focus. Some check-ins along the way would help keep us on track.”

Workshop

“We need to hit the ground running and get this project kicked off immediately. Our team has the ability to take this over once we get a framework and strategy in place.”

Consulting

“Our team does not have the time or the knowledge to take this project on. We need assistance through the entirety of this project.”

Diagnostics and consistent frameworks used throughout all four options

Guided Implementation

What does a typical GI on this topic look like?

A Guided Implementation (GI) is a series of calls with an Info-Tech analyst to help implement our best practices in your organization.

A typical GI is between 8 to 12 calls over the course of 4 to 9 months.

Workshop Overview

Contact your account representative for more information.
workshops@infotech.com 1-888-670-8889

Blueprint deliverables

Each step of this blueprint is accompanied by supporting deliverables to help you accomplish your goals:

Configuration Management Project Charter

Detail your approach to building an SCM practice and a CMDB.

Use Cases and Data Worksheet

Capture the action items related to your SCM implementation project.

Configuration Manager Job Description

Use our template for a job posting or internal job description.

Configuration Management Diagram Template Library

Use these diagrams to simplify building your SOP.

Configuration Management Policy

Set expectations for configuration control.

Configuration Management Audit and Validation Checklist

Use this framework to validate controls.

Configuration Control Board Charter

Define the board's responsibilities and meeting protocols.

Key deliverable:

Configuration Management Standard Operating Procedures Template

Outlines SCM roles and responsibilities, the CMDB data model, when records are expected to change, and configuration baselines.

Phase 1

Configuration Management Strategy

This phase will walk you through the following aspects of a configuration management system:

• Scope
• Use Cases
• Reports and Analytics

This phase involves the following participants:

• IT and business service owners
• Business/customer relationship managers
• Enterprise architects
• Practice owners and managers
• SCM practice manager
• SCM project manager
• SCM project sponsor

Harness Service Configuration Management Superpowers

Establish clear definitions

Ensure everyone is using the same terms.

What is a configuration management database (CMDB)?

The CMDB is a system of record of your services and includes a record for everything you need to track to effectively manage your IT services.

Anything that is tracked in your CMDB is called a configuration item (CI). Examples of CIs include:

• User-Facing Services
• IT-Facing Services
• Business Capabilities
• Relationships
• IT Infrastructure Components
• Enterprise Software
• End-User Devices
• Documents

Other systems of record can refer to CIs, such as:

• Ticket database: Tickets can refer to which CI is impacted by an incident or provided as part of a service request.
• Asset management database (AMDB): An IT asset is often also a CI. By associating asset records with CI records, you can leverage your IT asset data in your reporting.
• Financial systems: If done well, the CMDB can supercharge your IT financial cost model.

CMDBs can allow you to:

• Query multiple databases simultaneously (so long as you have the CI name field in each database).
• Build automated workflows and chatbots that interact with data across multiple databases.
• More effectively identify the potential impact of changes and releases.

Do not confuse asset with configuration

Asset and configuration management look at the same world through different lenses

• IT asset management (ITAM) tends to focus on each IT asset in its own right: assignment or ownership, lifecycle, and related financial obligations and entitlements.
• Configuration management is focused on configuration items (CIs) that must be managed to deliver a service and the relationships and integrations with other CIs.
• ITAM and configuration management teams and practices should work closely together. Though asset and configuration management focus on different outcomes, they may use overlapping tools and data sets. Each practice, when working effectively, can strengthen the other.
• Many objects will exist in both the CMDB and AMDB, and the data on those shared objects will need to be kept in sync.

*Discovery, dependency mapping, and data normalization are often features or modules of configuration management, asset management, or IT service management tools.

Start with ITIL 4 guiding principles to make your configuration management project valuable and realistic

Focus on where CMDB data will provide value and ensure the cost of bringing that data in will be reasonable for its purpose. Your end goal should be not just to build a CMDB but to use a CMDB to manage workload and workflows and manage services appropriately.

ITIL 4 guiding principles as described by AXELOS

Step 1.1

Identify use cases and desired benefits for service configuration management

Activities

1.1.1 Brainstorm data collection challenges

1.1.2 Define goals and how you plan to meet them

1.1.3 Brainstorm and prioritize use cases

1.1.4 Identify the data needed to reach your goals

1.1.5 Record required data sources

This step will walk you through the following aspects of a configuration management system:

• Scope
• Use cases

This phase involves the following participants:

• IT and business service owners
• Business/customer relationship managers
• Enterprise architects
• Practice owners and managers
• SCM practice manager
• Project sponsor
• Project manager

Identify potential obstacles in your organization to building and maintaining a CMDB

Often, we see multiple unsuccessful attempts to build out a CMDB, with teams eventually losing faith and going back to spreadsheets. These are common obstacles:

• Significant manual data collection, which is rarely current and fully accurate.
• Multiple discovery solutions creating duplicate records, with no clear path to deduplicate records.
• Manual dependency mapping that isn't accurate because it's not regularly assessed and updated.
• Hybrid cloud and on-premises environment with discovery solutions only partially collecting as the right discovery and dependency mapping solutions aren't in place.
• Dynamic environments (virtual, cloud, or containers) that may exist for a very short time, but no one knows how they should be managed.
• Lack of expertise to maintain and update the CMDB or lack of an assigned owner for the CMDB. If no one owns the process and is assigned as a steward of data, it will not be maintained.
• Database that was designed with other purposes in mind and is heavily customized, making it difficult to use and maintain.

Understanding the challenges to accessing and maintaining quality data will help define the risks created through lack of quality data.

This knowledge can drive buy-in to create a configuration management practice that benefits the organization.

1.1.1 Brainstorm data collection challenges

Involve stakeholders.
Allot 45 minutes for this discussion.

1. As a group, brainstorm the challenges you have with data:
2. Accuracy and trustworthiness: What challenges do you have with getting accurate data on IT services and systems?
   1. Access: Where do you have challenges with getting data to people when they need it?
   2. Manually created data: Where are you relying on data that could be automatically collected?
   3. Data integration: Where do you have issues with integrating data from multiple sources?
   4. Impact: What is the result of these challenges?
3. Group together these challenges into similar issues and identify what goals would help overcome them.
4. Record these challenges in the Configuration Management Project Charter, section 1.2: Project Purpose.

Download the Configuration Management Project Charter

Info-Tech Maturity Ladder

Identify your current and target state

INNOVATOR

• Characteristics of business partner
• Integration with orchestration tools

BUSINESS PARTNER

Data collection and validation is fully automated

Integrated with several IT processes

Meets the needs of IT and business use cases

TRUSTED OPERATOR

• Data collection and validation is partially or fully automated
• Trust in data accuracy is high, meets the needs of several IT use cases

FIREFIGHTER

• Data collection is partially or fully automated, validation is ad hoc
• Trust in data accuracy is variable, used for decision making

UNSTABLE

• Ad hoc or manual data collection and verification process
• Trust in data accuracy is low, and data is not easily or commonly used
• A more detailed assessment can be completed using Info-Tech's Configuration Management Audit and Validation Checklist.

INNOVATOR Characteristics of business partner Integration with orchestration tools BUSINESS PARTNER Data collection and validation is fully automated Integrated with several IT processes Meets the needs of IT and business use cases TRUSTED OPERATOR Data collection and validation is partially or fully automated Trust in data accuracy is high, meets the needs of several IT use cases FIREFIGHTER Data collection is partially or fully automated, validation is ad hoc Trust in data accuracy is variable, used for decision making UNSTABLE Ad hoc or manual data collection and verification process Trust in data accuracy is low, and data is not easily or commonly used A more detailed assessment can be completed using Info-Tech's Configuration Management Audit and Validation Checklist.

Define goals for your CMDB to ensure alignment with all stakeholders

• How are business or IT goals being hindered by not having the right data available?
• If the business isn't currently asking for service-based reporting and accountability, start with IT goals. This will help to develop goals that will be most closely aligned to the IT teams' needs and may help incentivize the right behavior in data maintenance.
• Configuration management succeeds by enabling its stakeholders to achieve their outcomes. Set goals for configuration management based on the most important outcomes expected from this project. Ask your stakeholders:
  1. What are the business' or IT's planned transformational initiatives?
  2. What are your highest priority goals?
  3. What should the priorities of the configuration management practice be?
• The answers to these questions will shape your approach to configuration management. Direct input from your leadership and executives, or their delegates, will help ensure you're setting a solid foundation for your practice.
• Identify which obstacles will need to be overcome to meet these goals.

"[T]he CMDB System should be viewed as a 'system of relevance,' rather than a 'single source of truth.' The burdens of relevance are at once less onerous and far more meaningful in terms of action, analysis, and automation. While 'truth' implies something everlasting or at least stable, relevance suggests a far more dynamic universe."

– CMDB Systems, Making Change Work in the Age of Cloud and Agile, Drogseth et al

Identify stakeholders to discuss what they need from a CMDB; business and IT needs will likely differ

Define your audience to determine who the CMDB will serve and invite them to these conversations. The CMDB can aid the business and IT and can be structured to provide dashboards and reports for both.

Nondiscoverable configuration items will need to be created for both audiences to organize CIs in a way that makes sense for all uses.

Integrations with other systems may be required to meet the needs of your audience. Note integrations for future planning.

1.1.2 Define goals and how you plan to meet them

Involve stakeholders.

Allot 45 minutes for this discussion.

As a group, identify current goals for building and using a CMDB.

Why are we doing this?

• How do you hope to use the data within the CMDB?
• What processes will be improved through use of this data and what are the expected outcomes?

How will we improve the process?

• What processes will be put in place to ensure data integrity?
• What tools will be put in place to improve the methods used to collect and maintain data?

Record these goals in the Configuration Management Project Charter, section 1.3: Project Objectives.

It's easy to think that if you build it, they will come, but CMDBs rarely succeed without solid use cases

Set expectations for your organization that defined and fulfilled use cases will factor into prioritization exercises, functional plans, and project milestones to achieve ROI for your efforts.

A good use case:

• Justifies resource allocation
• Gains funding for the right tools
• Builds stakeholder support
• Drives interest and excitement
• Gains support from anyone in a position to help build out and validate the data
• Helps to define success

In the book CMDB Systems, Making Change Work in the Age of Cloud and Agile, authors Drogseth, Sturm, and Twing describe the secrets of success:

A documented evaluation of CMDB System vendors showed that while most "best case" ROI fell between 6 and 9 months for CMDB deployments, one instance delivered ROI for a significant CMDB investment in as little as 2 weeks!

If there's a simple formula for quick time to value for a CMDB System, it's the following:

Mature levels of process awareness
+ Strong executive level support
+ A ready and willing team with strongly supportive stakeholders
+ Clearly defined and ready phase one use case
+ Carefully selected, appropriate technologies

All this = Powerful early-phase CMDB System results

Define and prioritize use cases for how the CMDB will be used to drive value

The CMDB can support several use cases and may require integration with various modules within the ITSM solution and integration with other systems.

Document the use cases that will drive your CMDB to relevance, including the expected benefits for each use case.

Identify the dependencies that will need to be implemented to be successful.

Define "done" so that once data is entered, verified, and mapped, these use cases can be realized.

"Our consulting experience suggests that more than 75% of all strategic initiatives (CMDB or not) fail to meet at least initial expectations across IT organizations. This is often due more to inflated expectations than categorical failure."

– CMDB Systems, Making Change Work in the Age of Cloud and Agile, Drogseth et al.

After identifying use cases, determine the scope of configuration items required to feed the use cases

On-premises software and equipment will be critical to many use cases as the IT team and partners work on network and data-center equipment, enterprise software, and integrations through various means, including APIs and middleware. Real-time and near real-time data collection and validation will ensure IT can act with confidence.

Cloud use can include software as a service (SaaS) solutions as well as infrastructure and platform as a service (IaaS and PaaS), and this may be more challenging for data collection. Tools must be capable of connecting to cloud environments and feeding the information back into the CMDB. Where on-premises and cloud applications show dependencies, you might need to validate data if multiple discovery and dependency mapping solutions are used to get a complete picture. Tagging will be crucial to making sense of the data as it comes into the CMDB.

In-house developed software would be beneficial to have in the CMDB but may require more manual work to identify and classify once discovered. A combination of discovery and tagging may be beneficial to input and classification.

Highly dynamic environments may require data collection through integration with a variety of solutions to manage and record continuous deployment models and verifications, or they may rely on tags and activity logs to record historical activity. Work with a partner who specializes in CI/CD to help architect this use case.

Containers will require an assessment of the level of detail required. Determine if the container is a CI and if the content will be described as attributes. If there is value to your use case to map the contents of each container as separate CIs within the container CI, then you can map to that level of detail, but don't map to that depth unless the use case calls for it.

Internet of Things (IoT) devices and applications will need to match a use case as well. IoT device asset data will be useful to track within an asset database but may have limited value to add to a CMDB. If there are connections between IoT applications and data warehouses, the dependencies should likely be mapped to ensure continued dataflow.

Out of scope

A single source of data is highly beneficial, but don't make it a catchall for items that are not easily stored in a CMDB.

Source code should be stored in a definitive media library (DML). Code can be linked to the CMDB but is generally too big to store in a CMDB and will reduce performance for data retrieval.

Knowledge articles and maintenance checklists are better suited to a knowledge base. They can also be linked to the CDMB if needed but this can get messy where many-to-many relationships between articles and CIs exist.

Fleet (transportation) assets and fixed assets should be in fleet management systems and accounting systems, respectively. Storing these types of data in the CMDB doesn't provide value to the support process.

1.1.3 Brainstorm and prioritize use cases

Which IT practices will you supercharge?

Focus on improving both operations and strategy.

1. Brainstorm the list of relevant use cases. What do you want to do with the data from the CMDB? Consider:
   1. ITSM management and governance practices
   2. IT operations, vendor orchestration, and service integration and management (SIAM) to improve vendor interactions
   3. IT finance and business service reporting needs
2. Identify which use cases are part of your two- to three-year plan, including the purpose for adding configuration data into that process. Prioritize one or two of these use cases to accomplish in your first year.
3. Identify dependencies to manage as part of the solution and define a realistic timeline for implementing integrations, modules, or data sources.
4. Document this table in the Configuration Management Project Charter, section 2.2: Use Cases.

Determine what additional data will be needed to achieve your use cases

Regardless of which use cases you are planning to fulfill with the CMDB, it is critical to not add data and complexity with the plan of resolving every possible inquiry. Ensure the cost and effort of bringing in the data and maintaining it is justified. The complexity of the environment will impact the complexity of data sources and integrations for discovery and dependency mapping.

Before bringing in new data, consider:

• Is this information available in other maintained databases now?
• Will this data be critical for decision making? If it is nice to have or optional, can it be automatically moved into the database and maintained using existing integrations?
• Is there a cost to bringing the data into the CMDB and maintaining it? Is that cost reasonable for its purpose?
• How frequently will this information be accessed, and can it be updated in an adequate cadence to meet these needs?
• When does this information need to be available?

Info-Tech Insight

If data will be used only occasionally upon request, determine if it will be more efficient to maintain it or to retrieve it from the CMDB or another data source as needed.

Remember, within the data sets, service configuration models can be used for:

• Impact analysis
• Cause and effect analysis
• Risk analysis
• Cost allocation
• Availability analysis and planning

1.1.4 Expand your use cases by identifying the data needed to reach your goals

Involve stakeholders.

Allot 60 minutes for this discussion.

Review use cases and their goals.

Identify what data will be required to meet those goals and determine whether it will be mandatory or optional/nice-to-have information.

Identify sources of data for each type of data. Color code or sort.

Italicize data points that can be automatically discovered.

Gain consensus on what information will be manually entered.

Record the data in the Use Cases and Data Worksheet.

Download the Use Cases and Data Worksheet

Use discovery and dependency mapping tools to automatically update the CMDB

Avoid manual data entry whenever possible.

Consider these features when looking at tools:

• Application dependency mapping: Establishing and tracking the relationships and dependencies between system components, applications, and IT services. The ideal tool will be able to generate maps automatically.
• Agentless and agent discovery: Scanning systems with both agent and agentless approaches. Agent-based scanning provides comprehensive information on applications used in individual endpoints, which is helpful in minimizing its IT footprint. However, agents require endpoint access. Agentless-based scanning provides a broader and holistic view of deployed applications without the need to install an agent on end devices, which can be good enough for inventory awareness.
• Data export capability: Easy exporting of application inventory information to be used in reports and other tools.
• Dashboards and chart visualization: Detailed list of the application inventory, including version number, number of users, licenses, deployment location, and other application details. These details will inform decision makers of each application's health and its candidacy for further rationalization activities.
• Customizable scanning scripts: Tailor your application discovery approach by modifying the scripts used to scan your systems.
• Integration with third-party tools: Easy integration with other systems with out-of-the-box plugins or customizable APIs.

Determine which data collection methods will be used to populate the CMDB

The effort-to-value ratio is an important factor in populating a CMDB. Manual efforts require a higher process focus, more intensive data validation, and a constant need to remind team members to act on every change.

• Determine what amount of effort is appropriate for each data grouping and use case. As decisions are made to expand data within the CMDB, the effort-to-value ratio should always factor in. To be usable, data must be accurate, and every piece of data that needs to be manually entered runs the risk of becoming obsolete.
• Identify which data sources will bring in each type of data. Where there is a possibility of duplicate records being created, one of the data sources will need to be identified as the primary.
• If the decision is to manually enter configuration items early in the process, be aware that automation may create duplicates of the CIs that will need to be deduplicated at some point in the process to make the information more usable.
• Typically, items are discovered, validated, then mapped, but there will be variations depending on the source.
• Active Directory or LDAP may be used to bring users and technicians into the CMDB. Data may be imported from spreadsheets. Identify efforts where data cleanup may have to happen before transferring into the CMDB.
• Identify how often manual imports will need to be conducted to make sure data is usable.

Identify other nondiscoverable data that will need to be added to or accessed by the CMDB

Foundational data, such as technicians, end users and approvers, roles, location, company, agency, department, building, or cost center, may be added to tables that are within or accessed by the CMDB. Work with your vendor to understand structure and where this information resides.

• These records can be imported from CSV files manually, but this will require manual removal or edits as information changes.
• Integration with the HRIS, Active Directory, or LDAP will enable automatic updates through synchronization or scheduled imports.
• If synchronization is fully enabled, new data can be added and removed from the CMDB automatically.
• Identify which nondiscoverable attributes will be needed, such as system criticality, support groups, groups it is managed by, location.
• If partially automating the process, identify where manual updates will need to occur.
• If fully automating the process, notifications will need to be set up when business owner or product or technical owner fields become empty to prompt defining a replacement within the CMDB.
• Determine who will manage these updates.
• Work with your CMDB implementation vendor to determine the best option for bringing this information in.

1.1.5 Record required data sources

Allot 15 minutes for this discussion.

1. Where do you track the work involved in providing services? Typically, your ticket database tracks service requests and incidents. Additional data sources can include:
   • Enterprise resource planning tools for tracking purchase orders
   • Project management information system for tracking tasks
2. What trusted data sources exist for the technology that supports these services? Examples include:
   • Management tools (e.g. Microsoft Endpoint Configuration Manager)
   • Architectural diagrams and network topology diagrams
   • IT asset management database
   • Spreadsheets
   • Other systems of record
3. What other data sources can help you gather the data you identified in activity 1.1.4?
4. Record the relevant data sources for each use case in the Configuration Management Standard Operating Procedures, section 6: Data Collection and Updates.

Info-Tech Insight

Improve the trustworthiness of your CMDB as a system of record by relying on data that is already trusted.

Step 1.2

Define roles and responsibilities

Activities

1.2.1 Record the project team and stakeholders

1.2.2 Complete a RACI chart to define who will be accountable and responsible for configuration tasks

This step will walk you through the following aspects of a configuration management system:

• Roles and responsibilities

This phase involves the following participants:

• IT service owners
• Enterprise architects
• Practice owners and managers
• SCM practice manager
• Project manager

Identify the roles you need in your SCM project

Determine which roles will need to be involved in the initial project and how to source these roles.

Leadership Roles
Oversee the SCM implementation

1. Configuration Manager – The practice owner for SCM. This is a long-term role.
2. Configuration Control Board (CCB) Chair – An optional role that oversees proposed alterations to configuration plans. If a CCB is implemented, this is a long-term role.
3. Project Sponsor or Program Sponsor – Provides the necessary resources for building the CMDB and SCM practices.
4. Architecture Roles
   Plan the program to build strong foundation
   1. Configuration Management Architect – Technical leader who defines the overall CM solution, plans the scope, selects a tool, and leads the technical team that will implement the solution.
   2. Requirements Analyst – Gathers and manages the requirements for CM.
   3. Process Engineer – Defines, documents, and implements the entire process.

Architecture Roles
Plan the program to build strong foundation

1. Configuration Management Architect – Technical leader who defines the overall CM solution, plans the scope, selects a tool, and leads the technical team that will implement the solution.
2. Requirements Analyst – Gathers and manages the requirements for CM.
3. Process Engineer – Defines, documents, and implements the entire process.

Engineer Roles
Implement the system

1. Logical Database Analyst (DBA) – Designs the structure to hold the configuration management data and oversees implementation.
2. Communications and Trainer – Communicates the goals and functions of CM and teaches impacted users the how and why of the process and tools.

Administrative Roles
Permanent roles involving long-term ownership

1. Technical Owner – The system administrator responsible for their system's uptime. These roles usually own the data quality for their system.
2. Configuration Management Integrator – Oversees regular transfer of data into the CMDB.
3. Configuration Management Tool Support – Selects, installs, and maintains the CM tool.
4. Impact Manager – Analyzes configuration data to ensure relationships between CIs are accurate; conducts impact analysis.

1.2.1 Record the project team and stakeholders

Allocate 25 minutes to this discussion.

1. Record the project team.

1. Identify the project manager who will lead this project.
2. Identify key personnel that will need to be involved in design of the configuration management system and processes.
3. Identify where vendors/outsourcers may be required to assist with technical aspects.
4. Document the project team in the Configuration Management Project Charter, section 1.1: Project Team.

2. Record a list of stakeholders.

1. Identify stakeholders internal and external to IT.
2. Build the stakeholder profile. For each stakeholder, identify their role, interest in the project, and influence on project success. You can score these criteria high/medium/low or score them out of ten.
3. If managed service providers will need to be part of the equation, determine who will be the liaison and how they will provide or access data.

Even with full automation, this cannot be a "set it and forget it" project if it is to be successful long-term

Create a team to manage the process and data updates and to ensure data is always usable.

• Services may be added and removed.
• Technology will change as technical debt is reduced.
• Vendors may change as contract needs develop.
• Additional use cases may be introduced by IT and the business as approaches to management evolve.
• AIOps can reduce the level of effort and improve visibility as configuration items change from the baseline and notifications are automated.
• Changes can be checked against requests for changes through automated reconciliations, but changes will still need to be investigated where they do not meet expectations.
• Manual data changes will need to be made regularly and verified.

"We found that everyone wanted information from the CMDB, but no one wanted to pay to maintain it. People pointed to the configuration management team and said, 'It's their responsibility.'

Configuration managers, however, cannot own the data because they have no way of knowing if the data is accurate. They can own the processes related to checking accuracy, but not the data itself."
– Tim Mason, founding director at TRM Associates
(Excerpt from Viewpoint: Focus on CMDB Leadership)

Include these roles in your CMDB practice to ensure continued success and continual improvement

These roles can make up the configuration control board (CCB) to make decisions on major changes to services, data models, processes, or policies. A CCB will be necessary in complex environments.

Configuration Manager

This role is focused on ensuring everyone works together to build the CMDB and keep it up to date. The configuration manager is responsible to:

• Plan and manage the standards, processes, and procedures and communicate all updates to appropriate staff. Focused on continual improvement.
• Plan and manage population of the CMDB and ensure data included meets criteria for cost effectiveness and reasonable effort for the value it brings.
• Validate scope of services and CIs to be included and controlled within the CMDB and manage exceptions.
• Audit data quality to ensure it is valid, is current, and meets defined standards.
• Evaluate and recommend tools to support processes, data collection, and integrations.
• Ensure configuration management processes interface with all other service and business management functions to meet use cases.
• Report on configuration management performance and take appropriate action on process adherence and quality issues.

Configuration Librarian

This role is most important where manual data entry is prevalent and where many nonstandard configurations are in place. The librarian role is often held by the tool administrator. The librarian focuses specifically on data within the CMDB, including:

• Manual updates to configuration data.
• CMDB data verification on a regular schedule.
• Processing ad hoc requests for data.

Product/Service/Technical Owners

The product or technical owner will validate information is correctly updating and reflects the existing data requirements as new systems are provisioned or as existing systems change.

Interfacing Practice Owners

All practice owners, such as change manager, incident manager, or problem manager, must work with the configuration team to ensure data is usable for each of the use cases they are responsible for.

Download the Configuration Manager job description

Assign configuration management responsibilities and accountabilities

Align authority and accountability.

• A RACI exercise will help you discuss and document accountability and responsibility for critical configuration management activities.
• When responsibility and accountability are not well documented, it's often useful to invite a representative of the roles identified to participate in this alignment exercise. The discussion can uncover contrasting views on responsibility and governance, which can help you build a stronger management and governance model.
• The RACI chart can help you identify who should be involved when making changes to a given activity. Clarify the variety of responsibilities assigned to each key role.
• In the future, you may need to define roles in more detail as you change your configuration management procedures.

Responsible: The person who actually gets the job done.
Different roles may be responsible for different aspects of the activity relevant to their role.

Accountable: The one role accountable for the activity (in terms of completion, quality, cost, etc.)
Must have sufficient authority to be held accountable; responsible roles are often accountable to this role.

Consulted: Those who need the opportunity to provide meaningful input at certain points in the activity; typically, subject matter experts or stakeholders. The more people you must consult, the more overhead and time you'll add to a process.

Informed: Those who receive information regarding the task but do not need to provide feedback.
Information might relate to process execution, changes, or quality.

Complete a RACI chart to define who will be accountable and responsible for configuration tasks

Determine what roles will be in place in your organization and who will fulfill them, and create your RACI chart to reflect what makes sense for your organization. Additional roles may be involved where there is complexity.

1.2.2 Complete a RACI chart to define who will be accountable and responsible for configuration tasks

Allot 60 minutes for this discussion.

1. Open the Configuration Management Standard Operating Procedures, section 4.1: Responsibility Matrix. In the RACI chart, review the top row of roles. Smaller organizations may not need a configuration control board, in which case the configuration manager may have more authority.
2. Modify or expand the process tasks in the left column as needed.
3. For each role, identify what that person is responsible for, accountable for, consulted on, or informed of. Fill out each column.
4. Document in the SOP. Schedule a time to share the results with organization leads.
5. Distribute the chart among all teams in your organization.
6. Describe additional roles as needed in the documentation.
7. Add accountabilities and responsibilities for the CCB into the Configuration Control Board Charter.
8. If appropriate, add auxiliary roles to the Configuration Management Standard Operating Procedures, section 4.2: Configuration Management Auxiliary Role Definitions.

Notes:

1. Assign one Accountable for each task.
2. Have one or more Responsible for each task.
3. Avoid generic responsibilities such as "team meetings."
4. Keep your RACI definitions in your documents for quick reference.

Refer back to the RACI chart when building out the communications plan to ensure accountable and responsible team members are on board and consulted and informed people are aware of all changes.

Phase 2

Configuration Management Data Model

This phase will walk you through the following aspects of a configuration management system:

• Data Model
• Customer-Facing and Supporting Services
• Business Capabilities
• Relationships
• IT Infrastructure Components
• Enterprise Software
• End-User Devices
• Documents

This phase involves the following participants:

• IT service owners
• Enterprise architects
• Practice owners and managers
• CM practice manager
• CM project manager

Step 2.1

Build a framework for CIs and relationships

Activities

Document services:

2.1.1 Define and prioritize your services

2.1.2 Test configuration items against existing categories

2.1.3 Create a configuration control board charter to define the board's responsibilities and protocols

This step will walk you through the following aspects of a configuration management system:

• Data model
• Configuration items
• Relationships

This phase involves the following participants:

• IT service owners
• Enterprise architects
• Practice owners and managers
• CM practice manager
• Project manager

Making sense of data daily will be key to maintaining it, starting with services

As CIs are discovered and mapped, they will automatically map to each other based on integrations, APIs, queries, and transactions. However, CIs also need to be mapped to a conceptional model or service to present the service and its many layers in an easily consumable way.

These services will need to be manually created or imported into the CMDB and manually connected to the application services. Services can be mapped to technical or business services or both.

If business services reporting has been requested, talk to the business to develop a list of services that will be required. Use terms the business will be expecting and identify which applications and instances will be mapped to those services.

If IT is using the CMDB to support service usage and reporting, develop the list of IT services and identify which applications and instances will be mapped to those services.

Work with your stakeholders to ensure catalog items make sense to them

There isn't a definitive right or wrong way to define catalog items. For example, the business and IT could both reference application servers, but only IT may need to see technical services broken down by specific locations or device types.

Refer back to your goals and use cases to think through how best to meet those objectives and determine how to categorize your services.

Define the services that will be the top-level, nondiscoverable services, which will group together the CIs that make up the complete service. Identify which application(s) will connect into the technical service.

When you are ready to start discovery, this list of services will be connected to the discovered data to organize it in a way that makes sense for how your stakeholders need to see the data.

While working toward meeting the goals of the first few use cases, you will want to keep the structure simple. Once processes are in place and data is regularly validated, complexities of different service types and names can be integrated into the data.

Define the service types to manage within the CMDB to logically group CIs

Determine which method of service groupings will best serve your audience for your prioritized use cases. This will help to name your service categories. Service types can be added as the CMDB evolves and as the audience changes.

2.1.1 Define and prioritize your services

Prioritize your starting point. If multiple audiences need to be accommodated, work with one group at a time.

Timing: will vary depending on number of services, and starting point

1. Create your list of services, referencing an existing service catalog, business continuity or disaster recovery plan, list of applications, or brainstorming sessions. Use the terminology that makes the most sense for the audience and their reporting requirements.
2. If this list is already in place, assess for relevance and reduce the list to only those services that will be managed through the CMDB.
3. Determine what data will be relevant for each service based on the exercises done in 1.1.4 and 1.1.5. For example, if priority was a required attribute for use case data, ensure each service lists the priority of that service.
4. For each of these, identify the supporting services. These items can come from your technical service catalog or list of systems and software.
5. Document this table in the Use Cases and Data Worksheet, tab 3: Service Catalog.

Service Record Example

Service: Email
Supporting Services: M365, Authentication Services

Service Attributes

Availability: 24/7 (99.999%)
Priority: Critical
Users: All
Used for: Collaboration
Billable: Departmental
Support: Unified Support Model, Account # 123456789

The CMDB will be organized by services and will enable data analysis through multiple categorization schemes

To extract maximum service management benefit from a CMDB, the highest level of CI type should be a service, as demonstrated below. While it is easier to start at the system or single-asset level, taking the service mapping approach will provide you with a useful and dynamic view of your IT environment as it relates to the services you offer, instead of a static inventory of components.

Level 1: Services

• Business Service Offering: A business service is an IT service that supports a business process, or a service that is delivered to business customers. Business service offerings typically are bound by service-level agreements.
• IT Service Offering: An IT service supports the customer's business processes and is made up of people, processes, and technology. IT service offerings typically are bound by service-level agreements.

Level 2: Infrastructure CIs

• IT Component Set: An IT service offering consists of one of more sets of IT components. An IT component set allows you to group or bundle IT components with other components or groupings.
• IT Component: An IT system is composed of one or more supporting components. Many components are shared between multiple IT systems.

Level 3: Supporting CIs

• IT Subcomponent: Any IT asset that is uniquely identifiable and a component of an IT system.
• IT components can have subcomponents, and those components can have subcomponents, etc.

Assess your CMDB's standard category offerings against your environment, with a plan to minimize customization

Standard categorization schemes will allow for easier integration with multiple tools and reporting and improve results if using machine learning to automate categorization. If the CMDB chosen includes structured categories, use that as your starting point and focus only on gaps that are not addressed for CIs unique to your environment.

There is an important distinction between a class and a type. This concept is foundational for your configuration data model, so it is important that you understand it.

• Types are general groupings, and the things within a type will have similarities. For attributes that you want to collect on a type, all children classes and CIs will have those attribute fields.
• Classes are a more specific grouping within a type. All objects within a class will have specific similarities. You can also use subclasses to further differentiate between CIs.
• Individual CIs are individual instances of a class or subclass. All objects in a class will have the same attribute fields and behave the same, although the values of their attributes will likely differ.
• Attributes may be discovered or nondiscoverable and manually added to CIs. The attributes are properties of the CI such as serial number, version, memory, processor speed, or asset tag.

Use inheritance structures to simplify your configuration data model.

Assess the list of classes of configuration items against your requirements

Types are general groupings, and the things within a type will have similarities. Each type will have its own table within the CMDB. Classes within a type are a more specific grouping of configuration items and may include subclasses.

Review your vendor's CMDB documentation. Find the list of CI types or classes. Most CMDBs will have a default set of classes, like this standard list. If you need to build your own, use the table below as a starting point. Define anything required for unique classes. Create a list and consult with your installation partner.

Sample list of classes organized by type

Review relationships to determine which ones will be most appropriate to map your dependencies

Your CMDB should include multiple relationship types. Determine which ones will be most effective for your environment and ensure everyone is trained on how to use them. As CIs are mapped, verify they are correct and only manually map what is incorrect or not mapping through automation.

Manually mapping CMDB relationships may be time consuming and prone to error, but where manual mapping needs to take place, ensure the team has a common view of the dependency types available and what is important to map.

Use automated mapping whenever possible to improve accuracy, provide functional visualizations, and enable dynamic updates as the environment changes.

Where a dependency maps to external providers, determine where it makes sense to discover and map externally provided CIs.

• Only connect where there is value in mapping to vendor-owned systems.
• Only connect where data and connections can be trusted and verified.

Most common dependency mapping types

2.1.2 Test configuration items against existing categories

Time to complete: 1-2 hours

1. Select a service to test.
2. Identify the various components that make up the service, focusing on configuration items, not attributes
3. Categorize configuration items against types and classes in the default settings of the CMDB.
4. Using the default relationships within the CMDB, identify the relationships between the configuration items.
5. Identify types, classes, and relationships that do not fit within the default settings. Determine if there are common terms for these items or determine most appropriate name.
6. Validate these exceptions with the publisher.
7. Document exceptions in the Configuration Management Standard Operating Procedures, Appendix 2: Types and Classes of Configuration Items

2.1.3 Create a configuration control board charter to define the board's responsibilities and protocols

A charter will set the tone for meetings, ensure purpose is defined and meeting cadence is set for regular reviews.

1. Open the Configuration Control Board Charter. Review the document and modify as appropriate for your CCB. This will include:
   • Purpose and mandate of the committee – Reference objectives from the project charter.
   • Team composition – Determine the right mix of team members. A team of six to ten people can provide a good balance between having a variety of opinions and getting work done.
   • Voting option – Determine the right quorum to approve changes.
   • Responsibilities – List responsibilities, starting with RACI chart items.
   • Authority – Define the control board's span of control.
   • Governing laws and regulations – List any regulatory requirements that will need to be met to satisfy your auditors.
   • Meeting preparation – Set expectations to ensure meetings are productive.
2. Distribute the charter to CCB members.

Assess the default list of statuses for each state

Align this list with your CMDB

Minimize the number of customizations that will make it difficult to update the platform.

1. Review the default status list within the tool.
2. Identify which statuses will be most used. Write a definition for each status.
3. Update this list as you update process documentation in Step 3.1. After initial implementation, this list should only be modified through change enablement.
4. Record this list of statuses in the Configuration Management Standard Operating Procedures, Appendix 4: Statuses

Step 2.2

Document statuses, attributes, and data sources

Activities

2.2.1 Follow the packet and map out the in-scope services and data centers

2.2.2 Build data model diagrams

2.2.3 Determine access rights for your data

This step will walk you through the following aspects of a configuration management system:

• Statuses
• Attributes for each class of CI

This phase involves the following participants:

• IT service owners
• Enterprise architects
• Practice owners and managers
• SCM practice manager
• Project manager

Outcomes of this step

• Framework for approaching CI statuses
• Attributes for each class of CI
• Data sources for those attributes

Service mapping approaches

As you start thinking about dependency mapping, it's important to understand the different methods and how they work, as well as your CMDB's capabilities. These approaches may be all in the same tool, or the tool may only have the top-down options.

Model hierarchy

Automated data mapping will be helpful, but it won't be foolproof. It's critical to understand the data model to validate and map nondiscoverable CIs correctly.

The framework consists of the business, enterprise, application, and implementation layers.

The business layer encodes real-world business concepts via the conceptual model.

The enterprise layer defines all enterprise data assets' details and their relationships.

The application layer defines the data structures as used by a specific application.

The implementation layer defines the data models and artifacts for use by software tools.

Learn how to create data models with Info-Tech's blueprint Create and Manage Enterprise Data Models

2.2.1 Follow the packet and map out the in-scope services and data centers

Reference your network topology and architecture diagrams.

Allot 1 hour for this activity.

1. Start with a single service that is well understood and documented.
2. Identify the technical components (hardware and applications) that make up the service.
3. Determine if there is a need to further break down services into logical service groupings. For example, the email service to the right is broken down into authentication and mail flow.
4. If you don't have a network diagram to follow, create a simple one to identify workflows within the service and components the service uses.
5. Record the apps and underlying components in the Configuration Management Standard Operating Procedures, Appendix 1: Configuration Data Model Structure.

This information will be used for CM project planning and validating the contents of the CMDB.

Download the Configuration Management Diagram Template Library to see an example.

Build your configuration data model

Rely on out-of-the-box functionality where possible and keep a narrow focus in the early implementation stages.

1. If you have an enterprise architecture, then your configuration management data model should align with it.
2. Keep a narrow focus in the early implementation stages. Don't fill up your CMDB until you are ready to validate and fix the data.
3. Rely on out-of-the-box (OOTB) functionality where possible. If your configuration management database (CMDB) and platform do not have a data model OOTB, then rely on a publicly available data model.
4. Map your business or IT service offering to the first few layers.

Once this is built out in the system, you can let the automated dependency mapping take over, but you will still need to validate the accuracy of the automated mapping and investigate anything that is incorrect.

Sample Configuration Data Model

Every box represents a CI, and every line represents a relationship

Example: Data model and CMDB visualization

Once the data model is entered into the CMDB, it will provide a more dynamic and complex view, including CIs shared with other services.

CMDB View

2.2.2 Build data model diagrams

Visualize the expected CI classes and relationships.

Allot 45 minutes.

1. Identify the different data model views you need. Use multiple diagrams to keep the information simple to read and understand. Common diagrams include:

1. Network level: Outline expected CI classes and relationships at the network level.
2. Application level: Outline the expected components and relationships that make up an application.
3. Services level: Outline how business capability CIs and service CIs relate to each other and to other types of CIs.

2. Use boxes to represent CI classes.
3. Use lines to represent relationships. Include details such as:

1. Relationship name: Write this name on the arrow.
2. Direction: Have an arrow point to each child.

Review samples in Configuration Management Diagram Template Library.
Record these diagrams in the Configuration Management Standard Operating Procedures, Appendix 1: Configuration Data Model Structure.

Download the Configuration Management Diagram Template Library to see examples.

Determine governance for data security, access, and validation

Align CMDB access to the organization's access control policy to maintain authorized and secure access for legitimate staff performing their role.

2.2.3 Determine access rights for your data

Allot 30 minutes for this discussion.

1. Open the Configuration Management Standard Operating Procedures, section 5: Access Rights.
2. Review the various roles from an access perspective.

1. Who needs read-only access?
2. Who needs read/write access?
3. Should there be restrictions on who can delete data?

3. Fill in the chart and communicate this to your CMDB installation vendor or your CMDB administrator.

Phase 3

Configuration Record Updates

This phase will walk you through the following aspects of a configuration management system:

• ITSM Practices and Workflows
• Discovery and Dependency Mapping Tools
• Auditing and Data Validation Practices

This phase involves the following participants:

• IT service owners
• Enterprise architects
• Practice owners and managers
• SCM practice manager
• SCM project manager
• IT audit

Harness Service Configuration Management Superpowers

Step 3.1

Keep CIs and relationships up to date through lifecycle process integrations

Activities

3.1.1 Define processes to bring new services into the CMDB

3.1.2 Determine when each type of CI will be created in the CMDB

3.1.3 Identify when each type of CI will be retired in the CMDB

3.1.4 Record when and how attributes will change

3.1.5 Institute configuration control and configuration baselines

This step will walk you through the following aspects of a configuration management system:

1. ITSM Practices and Workflows
2. Discovery and Dependency Mapping Tools

This phase involves the following participants:

1. IT service owners
2. Enterprise architects
3. Practice owners and managers
4. SCM practice manager
5. Project manager

Outcomes of this step

• List of action items for updating interfacing practices and processes
• Identification of where configuration records will be manually updated

Incorporate CMDB updates into IT operations

Determine which processes will prompt changes to the CMDB data

	Change enablement	Identify which process are involved in each stage of data input, maintenance, and removal to build out a process for each scenario.
	Project management
	Change enablement	Asset management	Security controls
	Project management	Incident management	Deployment management
	Change enablement	Asset management	Security controls
	Project management	Incident management	Service management

Formalize the process for adding new services to the CMDB

As new services and products are introduced into the environment, you can improve your ability to correctly cost the service, design integrations, and ensure all operational capabilities are in place, such as data backup and business continuity plans.
In addition, attributes such as service-level agreements (SLAs), availability requirements, and product, technical, and business owners should be documented as soon as those new systems are made live.

• Introduce the technical team and CCB to the product early to ensure the service record is created before deployment and to quickly map the services once they are moved into the production environment.
• Engage with project managers or business analysts to define the process to include security and technical reviews early.
• Engage with the security and technical reviewers to start documenting the service as soon as it is approved.
• Determine which practices will be involved in the creation and approval of new services and formalize the process to streamline entry of the new service, onboarding corresponding CIs and mapping dependencies.

3.1.1 Define processes to bring new services into the CMDB

Start with the most frequent intake methods, and if needed, use this opportunity to streamline the process.

1. Discuss the methods for new services to be introduced to the IT environment.
2. Critique existing methods to assess consistency and identify issues that could prevent the creation of services in the CMDB in a timely manner.
3. Create a workflow for the existing processes, with an eye to improvement. Identify any changes that will need to be introduced and managed appropriately.
4. Identify where additional groups may need to be engaged to ensure success. For example, if project managers are not interfacing early with IT, discuss process changes with them.
5. Discuss the validation process and determine where control points are. Document these on the workflows.
6. Complete the Configuration Management Standard Operating Procedures, section 8.1: Introduce New Service and Data Model.

Possible intake opportunities:

• Business-driven project intake process
• IT-driven project intake process
• Change enablement reviews
• Vendor-driven product changes

Identify scenarios where CIs are added and removed in the configuration management database

New CIs may be introduced with new services or may be introduced and removed as part of asset refreshes or through service restoration in incident management. Updates may be done by your own services team or a managed services provider.
Determine the various ways the CIs may be changed and test with various CI types.
Review attributes such as SLAs, availability requirements, and product, technical, and business owners to determine if changes are required.

• Identify what will be updated automatically or manually. Automation could include discovery and dependency mapping or synchronization with AMDB or AIOps tools.
• Engage with relevant program managers to define and validate processes.
• Identify control points and review audit requirements.

Info-Tech Insight

Data deemed no longer current may be archived or deleted. Retained data may be used for tracing lifecycle changes when troubleshooting or meeting audit obligations. Determine what types of CIs and use cases require archived data to meet data retention policies. If none do, deletion of old data may be appropriate.

3.1.2 Identify when each type of CI will be created in the CMDB

Allot 45 minutes for discussion.

1. Discuss the various methods for new CIs to be introduced to the IT environment.
2. Critique existing methods to assess consistency and identify issues that could prevent the creation of CIs in the CMDB in a timely manner.
3. Create a workflow for the existing processes, with an eye to improvement. Identify any changes that will need to be introduced and managed appropriately.
4. Identify where additional groups may need to be engaged to ensure success. For example, if project managers are not interfacing early with IT, discuss process changes with them.
5. Discuss the validation process and determine where control points are. Document these on the workflows.
6. Complete Configuration Management Standard Operating Procedures, section 8.2: Introduce New Configuration Items to the CMDB

Possible intake opportunities:

• Business-driven project intake process
• IT-driven project intake process
• Change enablement reviews
• Vendor-driven product changes
• Incident management
• Asset management, lifecycle refresh

3.1.3 Identify when each type of CI will be retired in the CMDB

Allot 45 minutes for discussion.

1. Discuss the various methods for CIs to be removed from the IT environment.
2. Critique existing methods to assess consistency and identify issues that could prevent the retirement of CIs in the CMDB in a timely manner.
3. Create a workflow for the existing processes, with an eye to improvement. Identify any changes that will need to be introduced and managed appropriately.
4. Identify where additional groups may need to be engaged to ensure success. For example, if project managers are not interfacing early with IT, discuss process changes with them.
5. Discuss the validation process and determine where control points are. Document these on the workflows.
6. Discuss data retention. How long will retired information need to be archived? What are the potential scenarios where legacy information may be needed for analysis?
7. Complete the Configuration Management Standard Operating Procedures, section 8.4: Retire and Archive Configuration Records.

Possible retirement scenarios:

• Change enablement reviews
• Vendor-driven product changes
• Incident management
• Asset management, lifecycle refresh

Determine appropriate actions for detecting new or changed CIs through discovery

Automated detection will provide the most efficient way of recording planned changes to CIs as well as detected unplanned changes. Check with the tool to determine what reports or notifications are available for the configuration management process and define what actions will be appropriate.

As new CIs are detected, identify the process by which they should have been introduced into configuration management and compare against those records. If your CMDB can automatically check for documentation, this may be easier. Weekly reporting will allow you to catch changes quickly, and alerts on critical CIs could enable faster remediation, if the tool allows for alerting. AIOps could identify, notify of, and process many changes in a highly dynamic environment.

The configuration manager may not have authority to act but can inform the process owners of unauthorized changes for further action. Once the notifications are forwarded to the appropriate process owner, the configuration manager will note the escalation and follow up on data corrections as deemed appropriate by the associated process owner.

3.1.4 Record when and how attributes will change

These lists will help with configuration control plans and your implementation roadmap.

1. List each attribute that will change in that CI type's life.
2. Write all the times that each attribute will change. Identify:

1. The name of the workflow, service request, process, or practice that modifies the attribute.
2. Whether the update is made automatically or manually.
3. The role or tool that updates the CMDB.

3. Update the relevant process or procedure documentation. Explicitly identify when the configuration records are updated.

Document these tables in Configuration Management Standard Operation Procedures, Section 8.7: Practices That Modify CIs.

Institute configuration control and configuration baselines where appropriate

A baseline enables an assessment of one or more systems against the desired state and is useful for troubleshooting incidents or problems and validating changes and security settings.

Baselines may be used by enterprise architects and system engineers for planning purposes, by developers to test their solution against production copies, by technicians to assess configuration drift that may be causing performance issues, and by change managers to assess and verify the configuration meets the target design.

Configuration baselines are a snapshot of configuration records, displaying attributes and first-level relationships of the CIs. Standard configurations may be integral to the success of automated workflows, deployments, upgrades, and integrations, as well as prevention of security events. Comparing current CIs against their baselines will identify configuration drift, which could cause a variety of incidents. Configuration baselines are updated through change management processes.
Configuration baselines can be used for a variety of use cases:

• Version control – Management of software and hardware versions, https://dj5l3kginpy6f.cloudfront.net/blueprints/harness-configuration-management-superpowers-phases-1-4/builds, and releases.
• Access control – Management of access to facilities, storage areas, and the CMS.
• Deployment control – Take a baseline of CIs before performing a release so you can use this to check against actual deployment.
• Identify accidental changes – Everyone makes mistakes. If someone installs software on the wrong server or accidentally drops a table in a database, the CMS can alert IT of the unauthorized change (if the CI is included in configuration control).

Info-Tech Insight

Determine the appropriate method for evaluating and approving changes to baselines. Delegating this to the CCB every time may reduce agility, depending on volume. Discuss in CCB meetings.

3.1.5 Institute configuration control and configuration baselines where appropriate

Only baseline CIs and relationships that you want to control through change enablement.

1. Determine criteria for capturing configuration baselines, including CI type, event, or processes.
2. Identify who will use baselines and how they will use the data. Identify their needs.
3. Identify CIs that will be out of scope and not have baselines created.
4. Document requirements in the SOP.
5. Ensure appropriate team members have training on how to create and capture baselines in the CMDB.
6. Document in the Configuration Management Standard Operating Procedures, section 8.5: Establish and Maintain Configuration Baselines.

Step 3.2

Validate data within the CMDB

Activities

3.2.1 Build an audit plan and checklist

This step will walk you through the following aspects of a configuration management system:

• Data validation and audit

This phase involves the following participants:

• IT service owners
• Enterprise architects
• Practice owners and managers
• SCM practice manager
• Project manager
• IT audit

Outcomes of this step

• Updates to processes for data validation
• Plan for auditing and validating the data in the CMDB

Audit and validate the CMDB

Review the performance of the supporting technologies and processes to validate the accuracy of the CMDB.

CM Audit Plan

• CM policies
• CM processes and procedures
• Interfacing processes
• Content within the CMDB

"If the data in your CMDB isn't accurate, then it's worthless. If it's wrong or inaccurate, it's going to drive the wrong decisions. It's going to make IT worse, not better."
– Valence Howden, Research Director, Info-Tech Research Group

Ensure the supporting technology is working properly

Does the information in the database accurately reflect reality?

Perform functional tests during audits and as part of release management practices.

Audit results need to have a clear status of "compliant," "noncompliant," or "compliant with conditions," and conditions need to be noted. The conditions will generally offer a quick win to improve a process, but don't use these audit results to quickly check off something as "done." Ensure the fix is useful and meaningful to the process.
The audit should cover three areas:

• Process: Are process requirements for the program well documented? Are the processes being followed? If there were updates to the process, were those updates to the process documented and communicated? Has behavior changed to suit those modified processes?
• Physical: Physical configuration audits (PCAs) are audits conducted to verify that a configuration item, as built, conforms to the technical documentation that defines and describes it.
• Functional: Functional configuration audits (FCAs) are audits conducted to verify that the development of a configuration item has been completed satisfactorily, the item has achieved the functional attributes specified in the functional or allocated baseline, and its technical documentation is complete and satisfactory.

Build auditing and validation of processes whenever possible

When technicians and analysts are working on a system, they should check to make sure the data about that system is correct. When they're working in the CMDB, they should check that the data they're working with is correct.

More frequent audits, especially in the early days, may help move toward process adoption and resolving data quality issues. If audits are happening more frequently, the audits can include a smaller scope, though it's important to vary each one to ensure many different areas have been audited through the year.

• Watch for data duplication from multiple discovery tools.
• Review mapping to ensure all relevant CIs are attached to a product or service.
• Ensure report data is logical.

Ensure the supporting technology is working properly

Does the information in the database accurately reflect reality?

Perform functional tests during audits and as part of release management practices.

Audit results need to have a clear status of "compliant," "noncompliant," or "compliant with conditions," and conditions need to be noted. The conditions will generally offer a quick win to improve a process, but don't use these audit results to quickly check off something as "done." Ensure the fix is useful and meaningful to the process.
The audit should cover three areas:

• Process: Are process requirements for the program well documented? Are the processes being followed? If there were updates to the process, were those updates to the process documented and communicated? Has behavior changed to suit those modified processes?
• Physical: Physical configuration audits (PCAs) are audits conducted to verify that a configuration item, as built, conforms to the technical documentation that defines and describes it.
• Functional: Functional configuration audits (FCAs) are audits conducted to verify that the development of a configuration item has been completed satisfactorily, the item has achieved the functional attributes specified in the functional or allocated baseline, and its technical documentation is complete and satisfactory.

More frequent audits, especially in the early days, may help move toward process adoption and resolving data quality issues. If audits are happening more frequently, the audits can include a smaller scope, though it's important to vary each one to ensure many different areas have been audited through the year.

• Watch for data duplication from multiple discovery tools.
• Review mapping to ensure all relevant CIs are attached to a product or service.
• Ensure report data is logical.

Identify where processes break down and data is incorrect

Once process stops working, data becomes less accurate and people find workarounds to solve their own data needs.

Data within the CMDB often becomes incorrect or incomplete where human work breaks down

• Investigate processes that are performed manually, including data entry.
• Investigate if the process executors are performing these processes uniformly.
• Determine if there are opportunities to automate or provide additional training.
• Select a sample of the corresponding data in the CMS. Verify if the data is correct.

Non-CCB personnel may not be completing processes fully or consistently

• Identify where data in the CMS needs to be updated.
• Identify whether the process practitioners are uniformly updating the CMS.
• Discuss options for improving the process and driving consistency for data that will benefit the whole organization.

Ensure that the data entered in the CMDB is correct

• Confirm that there is no data duplication. Data duplication is very common when there are multiple discovery tools in your environment. Confirm that you have set up your tools properly to avoid duplication.
• Build a process to respond to baseline divergence when people make changes without following change processes and when updates alter settings.
• Audit the system for accuracy and completeness.

3.2.1 Build an audit plan and checklist

Use the audit to identify areas where processes are breaking down.

Audits present you with the ability to address these pain points before they have greater negative impact.

1. Identify which regulatory requirements and/or auditing bodies will be relevant to audit processes or findings.
2. Determine frequency of practice audits and how they relate to internal audits or external audits.
3. Determine audit scope, including requirements for data spot checks.
4. Determine who will be responsible for conducting audits and validate this is consistent with the RACI chart.
5. Record audit procedures in the Configuration Management Standard Operating Procedures section 8.6: Verify and Review the Quality of Information Through Auditing.
6. Review the Configuration Management Audit and Validation Checklist and modify to suit your needs.

Download the Configuration Management Audit and Validation Checklist

Phase 4

Service Configuration Roadmap

This phase will walk you through the following aspect of a configuration management system:
Roadmap
This phase involves the following participants:

• IT service owners
• Enterprise architects
• Practice owners and managers
• SCM practice manager
• SCM project manager

Harness Service Configuration Management Superpowers

Step 4.1

Define measures of success

Activities

4.1.1 Identify key metrics to define configuration management success
4.1.2 Brainstorm and record desired reports, dashboards, and analytics
4.1.3 Build a configuration management policy

This phase will walk you through the following aspects of a configuration management system:

• Metrics
• Policy

This phase involves the following participants:

• IT service owners
• Enterprise architects
• Practice owners and managers
• SCM practice manager
• SCM project manager