Certified - ITIL Foundation v4

The glossary is the bedrock of ITIL Foundation, and in this episode we begin with terms from A through G. Having a strong grasp of these terms is essential because the exam frequently tests definitions directly, and because these words provide the vocabulary for the entire framework. Understanding them early means that when you encounter practices, principles, or scenarios later, you will not stumble over language. Think of this as laying down the grammar of a new language. At first, definitions may seem abstract, but as we continue, you will hear them in context again and again, until they feel natural. This alphabetical journey is designed not as a memorization drill but as a structured exploration, weaving meaning, examples, and context so that each term becomes familiar and usable in both the exam and your professional life.
Agile delivery is one of the first important terms. It refers to approaches that emphasize adaptive development, rapid feedback, and collaboration between teams. Agile contrasts with rigid, sequential methods by promoting iteration and responsiveness. In ITIL’s context, Agile delivery highlights that services must evolve continuously to meet changing needs. Imagine a software development team releasing small updates every two weeks, incorporating user feedback immediately rather than waiting for a major annual release. This adaptive approach reduces risk, increases value delivery, and supports the modern demand for speed. Understanding Agile is critical because ITIL 4 explicitly acknowledges its compatibility with service management, showing that structure and flexibility can work together rather than in opposition.
The agreed service level is another foundational term. It refers to the documented performance expectation between a provider and a consumer, often codified in a service level agreement, or SLA. The importance lies not in the document itself, but in the shared understanding it creates. For instance, a cloud provider might commit to ninety-nine point nine percent uptime, while a customer agrees on how incidents will be reported and tracked. This agreement sets realistic expectations and creates accountability. Without an agreed service level, misunderstandings quickly arise, leading to frustration on both sides. In the exam and in practice, always remember that an agreed service level is about clarity and trust, not just paperwork.
An asset, or information technology asset, is any valuable component used in service delivery. This can be hardware like servers, software like applications, or even intangible items like licenses and data. The key idea is that assets represent value, either directly or indirectly, to the organization. For example, a laptop given to an employee is an asset because it enables productivity, but so is the software license that allows them to use essential applications. Asset management ensures that these valuable items are tracked, maintained, and used effectively. In ITIL, recognizing something as an asset means acknowledging its role in creating or supporting services. Losing track of assets can lead to both financial waste and security risks.
Assurance is another important concept, referring to the confidence that services will perform as expected and comply with requirements. Assurance is not the same as warranty, though they are related. It is the broader sense of reliability and accountability, often achieved through audits, testing, and reporting. For example, a customer may feel assured when they see that a provider’s backup systems are regularly tested and certified. Assurance builds trust, particularly in regulated industries like finance or healthcare, where compliance is as important as functionality. In the ITIL context, assurance means that services are not only available but demonstrably aligned with commitments and standards. It is both a technical and a relational concept, rooted in confidence.
Availability is a term that may seem straightforward but carries precise meaning in service management. It refers to the ability of a service to perform its function when required. Availability is usually expressed as a percentage of uptime over a defined period, such as ninety-nine point five percent per month. The focus is not just on whether a service exists but whether it is usable when needed. For example, a website that works perfectly but crashes during peak shopping hours has failed on availability. High availability is achieved through redundancy, monitoring, and proactive design. In ITIL, availability is one of the cornerstones of customer trust, directly influencing the perceived value of a service.
A baseline is defined as a reference point used for comparison. In ITIL, baselines help measure improvement or deviation. For example, if you want to evaluate whether a new incident management process has reduced response time, you compare current performance against a baseline established before the change. Baselines provide the “before” picture that makes progress visible. Without them, improvement claims are unsubstantiated. They can be technical, such as system performance benchmarks, or organizational, such as employee satisfaction scores. In service management, baselines anchor continual improvement, allowing teams to say with confidence whether changes are delivering the intended benefits.
Benefit is closely tied to outcomes. It is a measurable improvement resulting from service delivery, experienced by the customer or organization. Benefits can be tangible, like reduced costs or faster response times, or intangible, like improved employee morale. The important aspect is measurability—benefits are not vague aspirations but observable results. For instance, moving to cloud services might reduce downtime, which is a measurable benefit for customers. Benefits also link directly to business cases, as they justify investment in services or changes. ITIL emphasizes benefits because service management is ultimately about creating value, and benefits are the concrete expression of that value in action.
Business capability is the organizational ability to achieve intended outcomes. While similar to individual skills, capability exists at the organizational level and depends on structures, processes, and resources working together. For example, a company’s capability to deliver online sales depends not only on its website but also on logistics, payment systems, and customer support. Capabilities are broader than assets or processes alone—they represent the coordinated ability to produce outcomes. In ITIL, recognizing business capabilities helps ensure that services are aligned with what the organization is actually able to deliver, preventing overpromises and building realistic strategies for improvement.
Business continuity is the ability to operate during and after a disruption. It ensures that critical services remain available or can be restored quickly when unexpected events occur, such as natural disasters, cyberattacks, or system failures. For example, a bank may have redundant data centers so that even if one is compromised, transactions can continue. Business continuity planning is not about avoiding disruptions altogether but about resilience—ensuring survival and functionality under adverse conditions. In ITIL, continuity is part of assurance and availability, reinforcing that services must be designed for stability even in the face of uncertainty.
Business impact refers to the effect of events on organizational objectives and value. An outage in an email system may be inconvenient, but an outage in an online trading platform may result in significant financial loss and reputational damage. Impact helps prioritize responses and investments, ensuring that resources are directed where they matter most. In ITIL, assessing business impact is essential for risk management and incident prioritization. It clarifies why some issues require urgent escalation while others can be scheduled later. By linking events to business objectives, impact transforms technical disruptions into business concerns, aligning IT with organizational priorities.
Capability is a more general term than business capability. It refers to an organizational aptitude to coordinate resources and activities effectively. Capabilities may be technical, cultural, or process-driven. For instance, an organization with strong analytical capability can use data to inform decisions quickly. Unlike individual skills, capabilities exist at scale, shaping how an organization operates as a whole. In ITIL, capability underpins practices, allowing organizations to translate frameworks into action. Without capability, even well-designed processes cannot deliver value. Building and maintaining capability is thus a central focus of continual improvement, ensuring that resources and activities align with strategic goals.
Capacity is defined as the maximum throughput achievable by a service or component. In other words, it is how much work the system can handle under normal conditions. For example, a web server might have the capacity to support ten thousand concurrent users. If demand exceeds capacity, performance degrades or fails entirely. Capacity management ensures that services are provisioned to meet expected demand while avoiding unnecessary over-provisioning. In ITIL, capacity is tied directly to both utility and warranty, because it affects whether a service is functional and reliable. Monitoring and planning for capacity ensures that performance remains stable as usage grows.
Change is a fundamental term in ITIL. It refers to the addition, modification, or removal of anything that could affect services. This definition is deliberately broad, covering everything from updating software to restructuring teams. The reason for this breadth is that changes, even small ones, can disrupt service if not managed properly. ITIL reframes change management as change enablement, emphasizing safe and efficient change rather than bureaucratic control. Understanding change as any adjustment that could impact services ensures vigilance and discipline. It also highlights the balance ITIL seeks: encouraging improvement while managing associated risks.
The change authority is the person or group accountable for approving or rejecting changes. Different types of changes may require different authorities: routine, low-risk changes might be authorized by a team lead, while high-risk changes could require approval from a change advisory board. This structure ensures that accountability matches risk. The exam may test whether you can distinguish between the concept of change itself and the authority responsible for it. In practice, clear identification of change authority prevents confusion and ensures that decisions are made by those with the appropriate perspective and responsibility.
Finally, the change schedule is the calendar view of authorized and planned changes. This schedule provides visibility into upcoming work, allowing teams to coordinate and avoid conflicts. For example, scheduling a system upgrade at the same time as a database migration might create unnecessary risk. The change schedule prevents such overlaps by giving all stakeholders a clear picture of when changes will occur. It also builds trust, as customers know when to expect disruptions or improvements. In ITIL, visibility through the change schedule supports governance, coordination, and communication, ensuring that change is not chaotic but managed.
For more cyber related content and books, please check out cyber author dot me. Also, there are other prepcasts on Cybersecurity and more at Bare Metal Cyber dot com.
A configuration item, often abbreviated as CI, is any component that must be managed in order to deliver a service. This definition is intentionally broad, covering everything from physical servers and laptops to software, documentation, and even staff roles. The key point is that configuration items are not random; they are components deliberately chosen because they influence service delivery. For example, a router in a network is a configuration item because its functioning directly affects availability. The importance of identifying CIs lies in visibility—when you know what your services depend on, you can track, control, and support them consistently. Without this clarity, troubleshooting and change management become guesswork.
To manage configuration items effectively, organizations rely on a configuration management system, or CMS. This is not a single tool but a set of tools and databases that collectively store and manage information about configuration items. A CMS supports decision-making by providing accurate, up-to-date data about relationships between components. For instance, if a service is disrupted, the CMS can show which servers, applications, or networks are linked, allowing teams to isolate the root cause quickly. In ITIL, the CMS is a backbone of control, ensuring that the complexity of modern services remains navigable rather than overwhelming.
Within the broader CMS lies the configuration management database, or CMDB. The CMDB is a specific repository that stores records of configuration items and their relationships. Think of it as the organized, detailed catalog of all components within a service ecosystem. For example, the CMDB might show that a particular application depends on a database, which in turn relies on a server housed in a specific data center. By mapping these dependencies, the CMDB supports change decisions, incident analysis, and impact assessments. Its value is in accuracy: an outdated or poorly maintained CMDB creates as much confusion as clarity. ITIL emphasizes that maintaining integrity in the CMDB is as important as having one in the first place.
Continual improvement is another cornerstone concept, defined as a recurring activity to enhance services and practices over time. It is not a one-off project but a cultural mindset embedded in daily work. For instance, after resolving an incident, a team may ask what process adjustment could prevent recurrence. That reflection is continual improvement in action. ITIL places continual improvement at the heart of the Service Value System, emphasizing that every practice and every role should seek better outcomes. The exam may test the definition, but the real-world importance lies in resilience: organizations that continually improve remain relevant, competitive, and aligned with customer needs.
Cost is a term that encompasses both financial and non-financial expenditures involved in provisioning and consuming services. Financial costs include obvious items like hardware purchases or staff salaries. Non-financial costs may include time, energy, or risk exposure. For example, implementing a new application incurs not only software licensing fees but also the training time employees must invest. ITIL emphasizes cost because value is always judged against it: a service is valuable only if the benefits outweigh the costs for both provider and consumer. By understanding cost in this broader sense, service management ensures more realistic evaluations of what is worthwhile to deliver or consume.
The role of the customer is distinct within ITIL’s framework. A customer is the person or group who defines the requirements for a service and accepts responsibility for the outcomes of service consumption. This differs from the user, who consumes the service, and the sponsor, who authorizes or funds it. For example, in an online learning platform, the customer may be the training manager who decides what the organization needs, while the users are employees taking the courses. Understanding this distinction is critical both for exam precision and for real-world alignment, because treating all stakeholders as “users” oversimplifies the roles and weakens clarity in service delivery.
Culture refers to the shared values, attitudes, and behaviors within an organization that shape how service management is carried out. Culture is less tangible than tools or processes but no less powerful. A culture that values openness and collaboration will interpret ITIL practices in ways that emphasize communication and visibility. By contrast, a culture that is rigid or siloed may struggle to implement principles like “think and work holistically.” In ITIL, culture is recognized as one of the four dimensions of service management, reminding us that technology alone cannot guarantee success. Aligning practices with culture ensures sustainability and genuine adoption.
Deliver and support is one of the value chain activities within the Service Value System. It refers to the set of activities required to provide services to customers and users at the expected quality. This includes handling incidents, fulfilling requests, and ensuring that services run smoothly on a day-to-day basis. For example, ensuring that an email system is available and resolving issues when they arise falls under deliver and support. The exam may test whether you can recall that this is a value chain activity, but in practice, it represents the visible face of service management, where customer experience is shaped most directly.
Deployment refers to moving new or changed components into a target environment, such as production. It is not the same as release, though the terms are often confused. Release involves making service components available to users, while deployment is the technical act of placing them in the environment. For example, developers may deploy code to servers, but the release may not be announced to users until testing is complete. In ITIL, distinguishing deployment from release ensures clarity about responsibilities and timing. This prevents confusion and supports smoother transitions from design to operation.
Design and transition is another value chain activity, focusing on ensuring that new or changed services are designed with quality and then moved into live environments effectively. This activity emphasizes planning, testing, and coordinating changes so that outcomes meet expectations. For example, launching a new customer portal requires careful design of functionality, security, and user experience, followed by a transition that minimizes disruption. By framing design and transition as a structured activity, ITIL ensures that innovation is not haphazard but purposeful and aligned with business goals.
Engage is the value chain activity dedicated to interacting with stakeholders to understand needs, align expectations, and maintain relationships. This activity recognizes that service management is not just about technology but about communication and trust. For example, engaging with customers through surveys or meetings ensures that services remain relevant. Engagement also ensures visibility—stakeholders see what is being delivered and how it is evolving. In the exam, recall that engage is one of the six value chain activities. In practice, it reminds us that without engagement, even technically sound services may fail to deliver perceived value.
An event in ITIL is defined as any change of state that is significant for the management of a service or component. Events may be normal, such as a server starting successfully, or abnormal, such as a disk reaching full capacity. Event management ensures that these signals are captured, categorized, and acted upon as needed. For example, an event might trigger an alert that prompts proactive maintenance before an incident occurs. Recognizing events as state changes rather than problems prevents overreaction and helps organizations filter the noise of constant activity, focusing only on what matters.
Experience refers to the perceived quality of interactions with a service. It emphasizes that value is not just about what a service does but how it feels to the user. For instance, a website that loads quickly but is confusing to navigate offers poor experience despite good performance metrics. In ITIL, experience is a vital dimension of value because customer perception ultimately determines satisfaction. By including experience alongside outcomes, ITIL acknowledges that services succeed or fail not only on functionality but also on usability, responsiveness, and emotional impact.
Feedback is the information loop used to refine services and practices. Without feedback, organizations operate blindly, unable to confirm whether services meet expectations. Feedback may come from formal mechanisms like surveys, or informal cues like user behavior. In ITIL, feedback underpins continual improvement, allowing organizations to measure outcomes, identify gaps, and adapt accordingly. For example, customer complaints about long response times provide feedback that incident management may need adjustment. Treating feedback as a resource rather than a burden ensures that services evolve to remain aligned with stakeholder needs.
Finally, governance is defined as the system of direction and control that ensures an organization’s activities align with strategy and objectives. In ITIL 4, governance is integrated into the Service Value System rather than treated as an external overlay. Governance ensures accountability, compliance, and strategic alignment across all service management activities. For example, a board setting policies on data privacy is exercising governance, ensuring that practices adhere to regulations and values. In both the exam and practice, governance is the bridge between high-level direction and operational execution. It ensures that services not only run effectively but also serve the organization’s broader mission.
As we conclude this glossary segment, you now have a foundation of terms from A through G that will reappear throughout the course. Each definition carries weight in the exam, but more importantly, each shapes how you think about service management. These terms form the vocabulary through which ITIL principles, practices, and value system components are expressed. By mastering them early, you reduce cognitive load in later episodes and strengthen your ability to recall and apply concepts fluently. In the next glossary installment, we will continue with key terms from H through P, expanding your language toolkit step by step.