IT Service Catalogue Security: Owners, Tiers, Admin Paths

When an incident hits a business service, responders lose hours finding out who owns it, how critical it is, what data it holds, how administrators reach it and which service accounts and API keys it depends on. Asset inventories describe components and entitlement catalogues describe access, but few organisations keep one record per service that ties those facts together. This guide shows how to make the IT service catalogue that record: the security attributes every service entry needs, how to rate criticality, how to document admin paths and non-human identities, how to keep the data accurate, and how incident response, access reviews, change and supplier management use it. It is for service owners, ITSM and CMDB owners, security architects and incident managers.

Key takeaways

The service is the unit people defend. Responders, executives and regulators think in services, so the security facts must be recorded at service level, not scattered across component records.
Every service needs a named owner and a criticality tier. Without them nobody can prioritise incidents, patches or reviews.
Admin paths and machine identities are part of the service. Record how the service is administered and which service accounts, keys and integrations it uses.
A catalogue entry is a claim that needs checking. Reconcile it with discovery, identity and cloud data on a schedule, and track data quality as a metric.
The catalogue is a target map. Restrict who can read the sensitive fields and who can change them.

Service record, asset record and entitlement record

Three neighbouring records are often confused. The Asset Inventory and CMDB Security Guide covers component records (servers, cloud resources, applications, certificates). The Entitlement Catalogue Guide covers what each grantable permission means and who approves it, and the Access Request and Approval Workflow Design Guide covers how users request access. The service record sits above them: it names the business service, links to its components and entitlements, and holds the facts that only make sense at service level.

Record	Unit	Answers	Typical owner
Service record (this guide)	A business or technical service, such as "Payroll" or "Customer identity platform"	Who owns it, how critical it is, what data it holds, how it is administered, what it depends on	Service owner
Asset or configuration item	A component: server, database, cloud account, SaaS tenant	What exists, where, in what state	Technical owner or platform team
Entitlement	A grantable permission: group, role, scope	What the access allows and who approves it	Entitlement owner
Identity record	A person or non-human identity	Who or what holds access, and its life cycle	Identity team, plus the identity's owner

The NCSC Cyber Assessment Framework describes the outcome under Principle A3, asset management: assets relevant to the secure operation of network and information systems are identified, inventoried and kept up to date, dependencies on supporting infrastructure are recorded, assets are prioritised by importance, and every relevant asset has someone responsible for it. A security-grade service catalogue is the way most IT organisations meet that at service level.

The security attributes every service entry needs

Our recommendation at NHI Mgmt Group is the minimum set below. Start with these fields for critical services before extending to the whole catalogue. A ready-to-use version is in the Service Security Register Template.

Attribute	What to record	Main source	Used by
Service owner	A named accountable person, plus a deputy; never a team mailbox alone	Service owner confirmation	Everyone
Technical owner and support group	Who runs it day to day and the on-call route, including supplier support	ITSM assignment groups	Incident response
Criticality tier	Tier from the business impact analysis (see below)	BIA	Prioritisation, patching, reviews
Data classification	Highest classification of data stored or processed, and personal data categories	Data owner, records of processing	Privacy, DLP, breach assessment
Recovery objectives	Recovery time and recovery point objectives agreed with the business	BIA, continuity plans	Resilience, backup design
Components	Links to configuration items: tenants, accounts, clusters, databases	CMDB and cloud inventory	Vulnerability management, IR scoping
Identity provider and authentication	Which directory or IdP users sign in with, and whether SSO and MFA are enforced	IdP application inventory	Access reviews, IR
Admin paths	Every way to administer the service: consoles, APIs, jump hosts, vendor support access, break-glass accounts	Service owner, PAM, cloud IAM	PAM, IR containment
Non-human identities	Service accounts, workload identities, API keys, OAuth apps and certificates the service uses or issues, each with an owner	Secrets manager, IdP, cloud IAM	NHI governance, rotation, IR
Upstream and downstream dependencies	Services and suppliers it relies on, and services that rely on it	Architecture, integration inventory	Impact analysis, change risk
Suppliers	SaaS, hosting and support providers, with contract owner	Supplier register	Third-party risk, supplier assurance
Logging	Where security logs go and retention	SIEM onboarding records	Detection, forensics
Last reviewed	Date the owner last confirmed the record	Attestation workflow	Data quality

Rating criticality

Criticality has to come from business impact, not from how loudly a team asks. NIST IR 8286D (updated February 2025) describes using business impact analysis to identify mission-essential functions, determine which assets support them and what makes them critical or sensitive, and then categorise assets and set protection requirements. Use a small number of tiers that drive concrete differences.

Tier (ours)	Definition	What it drives
Tier 0	Services that control other services: identity providers, directory, PAM, deployment and management platforms, backup	Strictest admin controls, quarterly access review, compromise playbook, isolated admin paths
Tier 1	Services whose loss stops a critical business function or exposes the most sensitive data	Short recovery objectives, quarterly review of admin and NHI access, tested recovery
Tier 2	Important services with workarounds available	Half-yearly reviews, standard recovery testing
Tier 3	Low impact or easily replaced services	Annual review, baseline controls

Tier 0 deserves its own label because compromise of an identity provider, a deployment tool or a backup platform affects every other service. Treat those services as the top of the catalogue, whatever their business visibility.

Documenting admin paths

Admin paths are the attribute most often missing and most needed during an incident. For each service, list every route to administrative control:

Human admin roles: The roles that grant admin rights, where they are assigned (IdP group, cloud role, application role) and whether they are standing or just-in-time.
Consoles and APIs: Admin consoles, management APIs and CLIs, with the network restrictions that apply.
Infrastructure routes: Hypervisor, cloud account or database access that bypasses the application's own controls.
Supplier access: Vendor support accounts, delegated admin relationships and remote support tools.
Break-glass accounts: Emergency accounts, where credentials are stored and how use is alerted.

When responders need to contain a compromised service, this list is the containment checklist. When access reviewers need to review a service, it tells them which roles matter. See the Break-Glass Account Guide.

Machine identities per service

Every service runs on non-human identities: the service account that connects the application to its database, the workload identity in the cloud account, the API key for a payment provider, the OAuth app that syncs data to a SaaS tool, and the certificates that secure its endpoints. Recording them against the service gives each one a business owner and a criticality, which is what NHI governance usually lacks. For each, record the identity, its type, where its credential is stored, its owner, its last rotation and the services it can reach. When a service is decommissioned, this list drives credential revocation so orphaned identities are not left behind. See the Service Account Security Guide.

How the catalogue is used

Incident response: Scope impact from the dependency map, contact the owner and support group, contain through the admin path list and rotate the service's NHI credentials. See Major Incident Management.
Access reviews: Review admin roles and NHIs per service, at a frequency set by tier, with the service owner as reviewer.
Change management: Rate change risk by tier and dependencies; changes to Tier 0 services get extra approval. See Change Management Security.
Vulnerability prioritisation: Combine severity with the tier of the service that a component supports.
Supplier assurance: Identify which suppliers support Tier 0 and Tier 1 services and apply stronger assurance; see IT Service-Level and Operational Supplier Assurance.
Problem management: Link recurring incidents to services to see where control gaps cluster; see Problem Management for Security.

Keeping the data accurate

Catalogues decay because owners change jobs and services change shape. Treat data quality as an operational process.

Owner attestation: Service owners confirm their records on a schedule set by tier, with escalation when they do not.
Reconciliation: Compare catalogue entries with IdP application lists, cloud accounts, SaaS discovery and secrets inventories. Anything discovered but not linked to a service is an orphan to resolve.
Joiner and leaver triggers: When a service owner leaves, the HR leaver event creates a task to reassign ownership.
Change hooks: New services cannot go live, and services cannot be decommissioned, without a catalogue update as a change requirement.
Quality scoring: Score each record on completeness of the required fields and recency of review, and report scores per owner.

Securing the catalogue itself

A service catalogue with admin paths, break-glass locations and NHI details is a map of the organisation's most valuable targets. Separate the general service description, which many people need, from sensitive security fields, which only owners, security and responders need. Limit write access to service owners and catalogue administrators, log changes to security fields, and alert on changes to Tier 0 records. Integrations that write to the catalogue use scoped service identities, not admin accounts. Planned guidance on hardening the platform itself is in Securing the ITSM platform itself and Securing the CMDB and asset inventory itself.

Choosing where to hold it

Small organisations: A controlled spreadsheet or wiki table with the minimum attributes for the 20 to 50 services that matter is better than an empty ITSM module. Restrict access and review it quarterly. Larger organisations: Hold the service record in the ITSM or CMDB platform so it can link to configuration items, incidents and changes, and feed it automatically from identity, cloud and secrets tooling. In both cases the attributes matter more than the tool.

How to implement

Agree the service list: Start with Tier 0 and Tier 1 candidates from the BIA and continuity plans.
Assign owners: Get each service owner to accept ownership in writing.
Populate the minimum fields: Owner, tier, data classification, admin paths, NHIs, dependencies and suppliers for critical services first.
Link sources: Connect the IdP, cloud inventory and secrets manager so components and identities can be linked rather than typed.
Use it once: Run a tabletop exercise for a Tier 0 compromise using only the catalogue, and record the gaps found.
Extend and automate: Roll out to remaining services, add reconciliation jobs, and start quality scoring.

Detection and measurement

Metric	Target (ours)
Tier 0 and Tier 1 services with all minimum fields complete	100%
Services with an owner who is a current employee	100%, checked monthly
Records reviewed within their tier's review period	95% or more
Discovered applications and NHIs not linked to a service	Falling month on month
Incidents where responders found owner and admin paths from the catalogue	Rising; ask in every post-incident review

Monitor the catalogue too: alert on bulk exports, changes to admin path or tier fields on Tier 0 services, and reads of sensitive fields by accounts outside security and service ownership groups.

Common failure patterns

Owner is a team or a leaver: The owner field says "IT Infrastructure" or names someone who left last year.
Everything is critical: No BIA behind the tiers, so tiering drives no decisions.
Admin paths missing: The catalogue lists user access but not cloud console, database or vendor support routes.
NHIs unrecorded: Service accounts and keys are tracked nowhere, so decommissioning leaves them active.
One-off population: The catalogue was built for an audit and never reconciled again.
Open to all: Every employee can read break-glass and admin path details.

Framework mapping

Framework	Reference	Relevance
NIST CSF 2.0	ID.AM-02; ID.AM-04; ID.AM-05; ID.AM-08	Service inventories, supplier services, prioritisation, life cycle
NIST CSF 2.0	GV.OC-04; GV.OC-05	Critical services and dependencies understood
NIST SP 800-53 Rev. 5	CM-8 System Component Inventory; PM-11 Mission and Business Process Definition; RA-9 Criticality Analysis	Components, business processes, criticality
NIST SP 800-53 Rev. 5	RA-2 Security Categorization; CP-2(8) Identify Critical Assets; AC-2 Account Management	Categorisation, critical assets, accounts per service
NIST IR 8286D	Business impact analysis for risk prioritisation	Criticality tiering
NCSC CAF	A3.a Asset management	Inventory, dependencies, prioritisation, ownership

Practitioner checklist

Create one service record per business and Tier 0 technical service.
Name an accountable owner and deputy for every service.
Set criticality tiers from a business impact analysis.
Record every admin path, including supplier and break-glass access.
Record each service's non-human identities with owner and rotation date.
Link components, entitlements, suppliers and dependencies.
Reconcile with identity, cloud and secrets data on a schedule.
Restrict and monitor access to sensitive catalogue fields.

IT Service Catalogue Security: Owners, Criticality and Access Paths Every Service Needs