Service Catalogue
A service catalogue is a structured inventory of IT services available to an organisation, containing sufficient detail for requesters to understand what each service provides and for IT staff to deliver it consistently. The catalogue functions as the authoritative record of IT’s commitments: what is offered, to whom, under what conditions, and with what level of support.
This reference defines the components that constitute a well-formed service catalogue entry. Use it when establishing a new catalogue, evaluating completeness of existing entries, or standardising service documentation across merged or federated organisations.
Catalogue structure
The service catalogue organises services into a hierarchy that supports both browsing and direct lookup. The top level divides services by audience and consumption model, with subsequent levels grouping related services by function.
+------------------------------------------------------------------+| SERVICE CATALOGUE |+------------------------------------------------------------------+| || +---------------------------+ +---------------------------+ || | BUSINESS SERVICES | | TECHNICAL SERVICES | || | (end-user facing) | | (IT-internal) | || +---------------------------+ +---------------------------+ || || +-------------+ +-------------+ +-------------+ || | Productivity| | Programme | | Business | || | Services | | Delivery | | Systems | || | | | Services | | | || | - Email | | - Data | | - Finance | || | - Calendar | | collection| | system | || | - File | | - Case | | - HR system | || | storage | | management| | - CRM | || | - Video | | - M&E | | | || | meetings | | platform | | | || +-------------+ +-------------+ +-------------+ || || +-------------+ +-------------+ +-------------+ || | Security | | Platform | | Network | || | Services | | Services | | Services | || | | | | | | || | - Identity | | - Cloud | | - Internet | || | - Endpoint | | hosting | | access | || | protection| | - Database | | - VPN | || | - SIEM | | - Backup | | - DNS | || +-------------+ +-------------+ +-------------+ || |+------------------------------------------------------------------+Business services are those consumed directly by end users to accomplish their work. A programme officer uses the data collection service; a finance manager uses the finance system. Business service entries describe capabilities in terms meaningful to the consumer, avoiding technical implementation details except where necessary for access or compatibility.
Technical services underpin business services but are consumed by IT staff or automated systems rather than end users directly. The backup service protects the finance system’s data; the identity service authenticates users to all other services. Technical service entries contain implementation specifics required for operations and integration.
This two-catalogue model reflects the distinct audiences and their information needs. Some organisations maintain a single catalogue with audience-specific views; the underlying data model remains the same regardless of presentation.
Service attributes
Each catalogue entry contains a defined set of attributes that together specify the service completely. Attributes divide into identification, scope, support, and operational categories.
Identification attributes
| Attribute | Definition | Example value |
|---|---|---|
| Service ID | Unique identifier, typically hierarchical | SVC-PROD-EMAIL-001 |
| Service name | Human-readable name | Email and Calendar |
| Service owner | Individual accountable for the service | Director of IT |
| Service manager | Individual responsible for daily operation | Systems Administrator |
| Version | Current catalogue entry version | 2.3 |
| Last reviewed | Date of most recent entry review | 2024-11-15 |
The service ID follows a naming convention that encodes category and sequence. The pattern SVC-{CATEGORY}-{NAME}-{SEQUENCE} produces identifiers like SVC-PROD-EMAIL-001 for the first email-related productivity service or SVC-TECH-BACKUP-002 for the second backup-related technical service. Consistent identifiers enable reliable cross-referencing in configuration management databases, incident records, and change requests.
Scope attributes
| Attribute | Definition | Example value |
|---|---|---|
| Description | Plain-language summary of what the service provides | Organisation-wide email and calendar for internal and external communication |
| Included components | Specific capabilities within the service | Email sending/receiving, shared calendars, contact lists, 50GB mailbox |
| Excluded components | Capabilities explicitly not part of this service | Email archiving beyond 2 years, third-party email client support |
| Eligible users | Who may request or consume the service | All staff, contractors with >3 month engagement |
| Geographic availability | Where the service is accessible | Global; some features restricted in high-risk contexts |
| Dependencies | Other services required for this service to function | Identity service, Internet access service |
The included/excluded distinction prevents scope ambiguity. When the email service entry explicitly states that third-party client support is excluded, users understand that Thunderbird configuration assistance falls outside IT’s commitment. Without explicit exclusions, every service boundary becomes a negotiation.
Dependencies create a service map showing which services rely on which others. When the identity service experiences an outage, the dependency chain identifies all affected business services within seconds rather than requiring manual assessment.
Support attributes
| Attribute | Definition | Example value |
|---|---|---|
| Support tier | Level of support commitment | Tier 2 |
| Service hours | When the service is expected to be available | 24/7 |
| Support hours | When support staff respond to issues | Monday-Friday 08:00-18:00 UTC |
| Target availability | Percentage uptime commitment | 99.5% monthly |
| Response time | Maximum time to initial response | 4 hours during support hours |
| Resolution target | Target time to restore service | 8 hours for Tier 2 incidents |
| Escalation path | Route for unresolved issues | Service desk → Systems team → Service manager |
Support attributes connect directly to organisational SLA commitments. The values shown in individual service entries derive from the support tier assigned to that service, ensuring consistency across all Tier 2 services. The tier system is detailed in the Support tier definitions section below.
Operational attributes
| Attribute | Definition | Example value |
|---|---|---|
| Request process | How to request the service or changes | Service desk ticket, category “Email” |
| Provisioning time | Typical time from request to delivery | Same day for existing staff |
| Cost model | How costs are allocated | Included in core IT budget |
| Cost per unit | Charge to consuming department if applicable | N/A (no recharge) |
| Capacity limits | Constraints on service consumption | 50GB per mailbox, 25MB attachment limit |
| Data classification | Maximum data sensitivity permitted | Internal and Confidential; not Restricted |
| Backup/recovery | Data protection provisions | Daily backup, 30-day retention, 4-hour RTO |
| Retirement date | Planned end-of-life if applicable | N/A |
The data classification attribute prevents inappropriate use. A service cleared only for Internal and Confidential data cannot store protection case files classified as Restricted. Users consulting the catalogue understand constraints before selecting a service for sensitive workloads.
Service categorisation
Services group into categories that reflect how they are consumed, funded, and supported. Three categorisation dimensions apply independently to each service.
By audience
The audience dimension distinguishes who consumes the service directly:
| Category | Characteristics | Catalogue treatment |
|---|---|---|
| End-user services | Consumed by non-IT staff through user interfaces | Business service catalogue, non-technical descriptions |
| IT operational services | Consumed by IT staff to deliver other services | Technical service catalogue, implementation details |
| Integration services | Consumed by systems through APIs | Technical catalogue, API specifications, rate limits |
A single underlying platform may expose multiple services to different audiences. The identity platform provides an end-user service (password reset self-service), an IT operational service (user provisioning), and an integration service (authentication API). Each appears as a distinct catalogue entry with audience-appropriate attributes.
By criticality
Criticality determines recovery priority during incidents and resource allocation during capacity constraints:
| Category | Definition | Recovery priority | Example services |
|---|---|---|---|
| Critical | Service loss immediately halts core operations | Restore within 4 hours | Email, finance system, identity |
| Important | Service loss significantly impairs operations within 24 hours | Restore within 24 hours | Document storage, HR system, CRM |
| Standard | Service loss causes inconvenience but workarounds exist | Restore within 72 hours | Intranet, training platform |
| Developmental | Service supports improvement activities, not operations | Restore as capacity allows | Test environments, sandboxes |
Criticality assignments require business input. IT cannot determine that email is more critical than the case management system without understanding programme delivery dependencies. The assignment process involves service owners and key stakeholders reviewing business impact at each recovery timeframe.
By funding model
The funding dimension determines how service costs flow through the organisation:
| Category | Mechanism | When to use |
|---|---|---|
| Core-funded | IT central budget absorbs all costs | Universal services, infrastructure |
| Cost-recovery | Consuming departments reimburse IT | Services with variable consumption |
| Grant-charged | Specific grants bear service costs | Project-specific services |
| External | Third party provides and funds service | Donated or partner-provided services |
Funding categorisation connects to Funding IT Operations for the mechanisms by which costs move between budgets. The catalogue entry records the category; the funding model determines the rates and allocation bases.
Support tier definitions
Support tiers standardise the commitment level across services, ensuring that all Tier 2 services receive equivalent response times regardless of the underlying technology. Four tiers accommodate the range from critical infrastructure to best-effort conveniences.
| Tier | Availability target | Support hours | Response time | Resolution target | Typical services |
|---|---|---|---|---|---|
| 1 | 99.9% | 24/7 | 30 minutes | 2 hours | Identity, core network, security monitoring |
| 2 | 99.5% | Extended (06:00-22:00) | 2 hours | 8 hours | Email, finance system, primary applications |
| 3 | 99.0% | Business hours | 4 hours | 24 hours | Secondary applications, collaboration tools |
| 4 | 95.0% | Business hours, best effort | Next business day | 72 hours | Development tools, non-critical utilities |
These targets represent organisational commitments balanced against operational capacity. A single IT person supporting 50 users cannot deliver Tier 1 support for multiple services; the tier assignments must reflect sustainable capacity. Organisations with minimal IT functions assign Tier 1 to at most two or three services, with remaining services at Tier 3 or 4.
The availability percentage translates to permitted downtime:
| Availability | Monthly downtime permitted | Annual downtime permitted |
|---|---|---|
| 99.9% | 43 minutes | 8.7 hours |
| 99.5% | 3.6 hours | 43.8 hours |
| 99.0% | 7.2 hours | 87.6 hours |
| 95.0% | 36 hours | 438 hours |
Availability calculations exclude planned maintenance windows announced at least 72 hours in advance. A service experiencing 5 hours of unplanned outage in a month fails the 99.5% target regardless of maintenance windows.
Example catalogue entries
The following entries demonstrate complete service documentation for a representative business service and technical service.
Business service example: Data Collection Platform
+------------------------------------------------------------------+| SERVICE CATALOGUE ENTRY |+------------------------------------------------------------------+| Service ID: SVC-PROG-DATACOLL-001 || Service name: Data Collection Platform || Version: 3.1 || Last reviewed: 2024-10-20 |+------------------------------------------------------------------+
IDENTIFICATION Service owner: Director of Programmes Service manager: M&E Systems Coordinator
DESCRIPTION Mobile and web-based data collection for programme monitoring, surveys, and assessments. Supports offline data entry with automatic synchronisation when connectivity is available.
INCLUDED COMPONENTS - Form design and deployment (up to 500 active forms) - Mobile app for Android and iOS - Offline data collection with sync - Basic data validation and skip logic - Data export (Excel, CSV, API) - User management for up to 200 data collectors - 50GB storage allocation
EXCLUDED COMPONENTS - Advanced analysis (use BI platform service) - Custom integrations (request via IT Planning) - SMS-based data collection (separate service) - Storage beyond 50GB (request expansion)
ELIGIBLE USERS Programme staff, M&E officers, authorised partner staff
GEOGRAPHIC AVAILABILITY Global; mobile app functions offline in all contexts
DEPENDENCIES - Identity service (authentication) - Internet access (for sync and web interface)
SUPPORT Tier: 3 Service hours: 24/7 (platform available) Support hours: Monday-Friday 08:00-18:00 UTC Availability: 99.0% monthly Response time: 4 hours during support hours Resolution target: 24 hours
OPERATIONS Request process: Service desk, category "Data Collection" Provisioning: New user: same day; new project: 3 days Cost model: Core-funded (basic); grant-charged (expansion) Data classification: Up to Confidential Backup: Daily, 90-day retention, 24-hour RTO
ESCALATION PATH Service desk → M&E Systems Coordinator → Director of ProgrammesTechnical service example: Backup and Recovery
+------------------------------------------------------------------+| SERVICE CATALOGUE ENTRY |+------------------------------------------------------------------+| Service ID: SVC-TECH-BACKUP-001 || Service name: Backup and Recovery Service || Version: 2.0 || Last reviewed: 2024-09-15 |+------------------------------------------------------------------+
IDENTIFICATION Service owner: IT Manager Service manager: Infrastructure Lead
DESCRIPTION Automated backup of organisation data and systems with defined retention periods and tested recovery capabilities. Provides data protection for all catalogued services according to their classification and criticality.
INCLUDED COMPONENTS - Daily incremental backup of all production systems - Weekly full backup with offsite replication - 30-day retention (standard), 90-day (extended), 7-year (archive) - Self-service file recovery (last 7 days) - Assisted recovery for older data - Monthly backup integrity verification - Annual recovery testing
EXCLUDED COMPONENTS - Endpoint backup (covered by endpoint protection service) - Real-time replication (request separately for critical systems) - Application-level recovery (application team responsibility)
CONSUMING SERVICES All Tier 1, 2, and 3 business and technical services
DEPENDENCIES - Storage platform (backup target) - Network services (data transfer) - Encryption service (backup encryption)
SUPPORT Tier: 1 Service hours: 24/7 (automated) Support hours: 24/7 (on-call for recovery) Availability: 99.9% monthly Response time: 30 minutes for recovery requests Resolution target: Per consuming service RTO
OPERATIONS Request process: Automatic inclusion; changes via change mgmt Cost model: Core-funded (allocated by storage consumed) Capacity: Current: 15TB; Maximum: 50TB
TECHNICAL SPECIFICATIONS Backup software: Restic 0.16+ Encryption: AES-256 at rest and in transit Offsite location: Geographic region >500km from primary Verification: SHA-256 integrity check on all backups
RECOVERY TIME OBJECTIVES Tier 1 services: 2 hours Tier 2 services: 4 hours Tier 3 services: 24 hours Tier 4 services: 72 hoursCatalogue governance
The service catalogue requires ongoing maintenance to remain accurate. Governance mechanisms prevent decay without imposing excessive overhead.
Each service entry has a designated service manager responsible for accuracy. The Last reviewed attribute tracks when someone confirmed the entry reflects current reality. Entries not reviewed within 12 months appear on an exception report for the IT manager.
Changes to service entries follow a lightweight process. Updates to descriptive text (clarifications, typo corrections) require only service manager approval. Changes to support attributes (tier, availability, response times) require service owner approval and communication to affected users. Changes that reduce service levels or eliminate components require 30 days notice.
New services enter the catalogue when they reach production status. The service design process documented in IT Planning and Prioritisation produces catalogue entries as a standard deliverable before go-live approval.
Service retirement follows a defined sequence: announcement of retirement date, migration support period, service marked as retiring in catalogue, final decommission, catalogue entry archived with retirement date recorded. The minimum announcement period is 90 days for Tier 3 and 4 services, 180 days for Tier 1 and 2 services.
Catalogue access and presentation
The catalogue exists in a canonical data form that supports multiple presentation interfaces tailored to different audiences.
Staff-facing presentation emphasises discoverability and plain language. A web-based portal allows browsing by category, searching by keyword, and filtering by eligibility. Each entry displays business-relevant attributes prominently, with technical details available on expansion. Request buttons link directly to the service desk with appropriate categories pre-filled.
IT-facing presentation includes operational detail. The same portal with an IT view shows dependencies, technical specifications, and integration information. Links connect to monitoring dashboards, runbooks, and configuration management records.
Machine-readable presentation exports catalogue data for integration with other systems. The configuration management database imports service records to link with configuration items. The service desk imports service names and categories to populate request forms. Monitoring systems import availability targets to configure alerting thresholds.
The canonical data store uses a structured format (database, structured documents, or IT service management platform) that enforces attribute completeness and enables automated validation. Spreadsheet-based catalogues are adequate for organisations with fewer than 20 services but become difficult to maintain and integrate as the catalogue grows.
See also
- IT Operating Models for the governance context in which services are defined
- Service Management Framework for how catalogued services are operated
- SLA Management for service level agreement procedures
- IT Planning and Prioritisation for how new services are approved