A service portfolio gives IT a complete view of the services an organization provides, is developing, or plans to retire. It brings these services together in one place, showing where they stand in their lifecycle and how they support business needs.
A service portfolio helps IT teams assess the value, cost, and status of their services as they move from planning to delivery and eventually retirement. It also provides a broader view of the organization’s service offering than the service catalog, which focuses on the services currently available to users.
Understanding how the service portfolio works, what it contains, and how it differs from the service catalog is essential for managing IT services throughout their lifecycle.
What is a service portfolio?
A service portfolio is the complete list of everything your IT team offers, across three stages: services that are live today, services being planned, and services being retired.
The part your users actually see and request from — the live services — is the service catalog. The catalog is the storefront. The portfolio is the full inventory behind it, including what's coming and what's on its way out.
Defined in ITIL, the service portfolio broadens the view to cover IT services across their entire lifecycle, from first idea to retirement. It gives organizations a way to align services with business goals, track investment, and make informed decisions about what to offer.
The three components of a service portfolio
Every service portfolio is organized into three parts, each representing a different stage in a service's life:
- The service pipeline — proposed services and services under development. Pipeline services are not yet live or available to users. This section documents what IT plans to offer and when it expects those services to arrive.
- The service catalog — the services offered right now. Every entry is live and available to the business, with the details users need to request it.
- Retired services — services that have been or are being withdrawn, along with the historical record for each one. This information supports users and applications that still depend on legacy services during and after the transition.
Service portfolio vs. service catalog
The service portfolio and the service catalog are closely related, and the catalog sits inside the portfolio as its live, customer-facing layer. The difference comes down to scope and audience:
- The service portfolio encompasses all IT services across their entire lifecycle, from conceptualization to retirement. It covers everything from legacy services that are no longer being used, active services via the service catalog, and future services that are under consideration by the business. In addition, it provides a strategic overview of all services, allowing organizations to prioritize, plan, and make decisions based on aligning IT services with business objectives.
- The service catalog is a subset of the service portfolio; it communicates all available services to the end user community and promotes their availability and support details. It is a shop window for IT services, much like an online shopping catalog. It includes information such as service descriptions, service levels, pricing (if applicable), and any relevant user instructions.
| Service portfolio | Vs. | Service catalog |
| Planned, live, and retired services | Covers | Live services only |
| IT leaders and service owners | Used by | End users and customers |
| Strategic view of the full service offering | Level | Operational view of available services |
| Lifecycle status, costs, value, and business cases | Includes | Service descriptions, service levels, and request options |
| Supports service strategy and investment decisions | Purpose | Helps users find and request services |
| Covers the entire service lifecycle | Lifecycle | Focuses on services currently available |
Examples of IT services (and where they sit in the portfolio)
A service is a capability IT delivers to its users as a complete, ready-to-use outcome. Users request the result — a working laptop, access to an application, a resolved issue — without needing to manage the servers, licenses, and teams that produce it. Each service can also contain more specific service offerings: variations of the same service tailored to different needs.
Common IT services, with examples of the offerings that can sit under each:
- Email and calendaring — mailbox setup, shared mailboxes, distribution lists, and more.
- Device provisioning — new laptop, replacement laptop, mobile phone, and more.
- Network access — office Wi-Fi, VPN and remote access, guest access, and more.
- Printing — local printer setup, network printer access, and more.
- Identity and access — password reset, new user account, application access, and more.
- Telephony — desk phone, softphone, voicemail, and more.
- Software — standard app install, license request, specialized software approval, and more.
Mapping these services across the three parts of the portfolio shows how the model works in practice:
- In the service catalog (live and requestable): email, VPN access, laptop requests, password resets.
- In the pipeline (planned or in pilot): a self-service chatbot being tested with one department, a cloud storage platform scheduled to replace an on-premise file server.
- Retired (kept for history and legacy support): an old VPN client, a decommissioned file server that a few older applications still depend on.
The catalog is the layer users browse and order from. The portfolio holds all three groups together, giving IT a single view to plan, budget, and support every service across its lifecycle.
How to build a service portfolio
Building a service portfolio is largely a consolidation exercise. Most IT teams already hold much of the required information across a service catalog, a ticketing system, and asset records; the work is to gather it and organize it into one lifecycle view. A common approach follows six steps:
- Start where you are — build on what already exists. Use the service catalog as a base, pull the most frequently logged tickets from the service desk, and work with project and business teams to map planned services.
- Set the scope — define what the portfolio is meant to achieve and communicate it to stakeholders. Keep the first version realistic.
- List every service — compile a single list of all services: planned, live, and retired. The IT Asset Management (ITAM) team can help fill in the details.
- Sort and prioritize — group services into planned, live, and retired, then rank them by business alignment, demand, and available resources.
- Add the details — for each service, capture a description, availability, service owner, where to get help, and links to its SLAs.
- Put it to work — deploy the catalog part of the portfolio into the service desk so users can find and request services easily, and set a regular cadence to review, add, and retire services over time.
How a service portfolio supports other ITIL practices
A well-maintained service portfolio reinforces several other ITIL practices:
- Problem Management — the pipeline and a prioritized service list help teams focus resolution efforts on business-critical services.
- Change Enablement — a visible service ecosystem makes it easier to assess the impact of a change.
- Service Level Management — promoting the portfolio across the business makes SLAs more visible and accessible.
