When a service is attacked or fails, the first questions are always the same: who owns it, how critical is it, how do administrators reach it, and which service accounts, keys and certificates does it run on, and most organisations cannot answer them in one place. Asset registers list devices and software; entitlement catalogues list permissions. Neither records the security facts of a business or IT service as a whole. This template defines a service security register: one record per service with its owners, criticality, administration path, machine identities, dependencies and recovery evidence. It is written for IT operations, service owners, security architects and incident responders, and can be kept in a spreadsheet, a CMDB service class or an ITSM service catalogue. Asset-level fields are in the IT Asset Inventory Template and permission ownership in the Entitlement Catalogue Guide; this register links to both rather than repeating them.
How to use this template
- Replace text in square brackets, such as [Organisation], [Register owner] and [ITSM tool], with your own values.
- Create one record per service a user or another system consumes, such as "Payroll", "Customer API", "Corporate VPN" or "Active Directory". Do not create records per server; link servers by Asset ID.
- Fields marked Required are the minimum before a service goes live. Fields marked Recommended make the register useful during incidents.
- Never record a secret in the register. Record the identity, where its credential is held and who owns it.
- Restrict access. A complete register is a map of how to reach and control every important service, so treat it as confidential. See Securing the CMDB and asset inventory itself.
1. Purpose
1.1 This register records, for every service [Organisation] operates or depends on, the accountable owners, the business criticality, the approved administration path, the non-human identities the service uses, its key dependencies and its recovery evidence.
1.2 It supports incident response, change risk assessment, access reviews, business continuity and audit. It meets the intent of the NCSC Cyber Assessment Framework principle A3, which asks that everything needed to deliver essential functions, including data, people, systems and supporting infrastructure, is determined and understood.
2. Scope
2.1 In scope: all production business services, shared IT and security platforms (identity provider, directory, PAM, backup, logging, network core) and third-party services that hold [Organisation] data or credentials.
2.2 Out of scope: [list, for example development sandboxes with no production data]. Record the reason for each exclusion.
2.3 A new service may not enter production until its Required fields are complete and approved by the [Register owner].
3. Roles and responsibilities
| Role | Responsibility |
|---|---|
| [Register owner] | Maintains the template, runs reviews, reports completeness metrics |
| Business owner | Accountable for the service, its criticality rating and risk acceptance |
| Technical owner | Keeps the record accurate: admin path, identities, dependencies, recovery |
| Security architect | Reviews Critical and High records and admin path exceptions |
| Identity team | Confirms that each listed machine identity exists, has an owner and matches the identity inventory |
4. Service identity and ownership fields
| Field | Status | Guidance |
|---|---|---|
| Service ID | Required | Unique ID, for example SVC-0042, used in tickets, runbooks and alerts |
| Service name and description | Required | Name users recognise; one sentence on what it does |
| Business owner | Required | Named person, linked to the directory so a leaver is flagged |
| Technical owner and deputy | Required | Named people, never only a team mailbox |
| Support group and on-call route | Required | [ITSM tool] assignment group and escalation contact |
| Hosting model | Required | On premises, IaaS, PaaS, SaaS or hybrid; provider name for SaaS |
| Linked assets | Recommended | Asset IDs from the asset register |
| Lifecycle status | Required | Planned, live, retiring, retired |
5. Criticality
5.1 Rate each service using [Organisation]'s business impact analysis. See the Business Impact Analysis Template.
| Field | Status | Guidance |
|---|---|---|
| Criticality | Required | Critical, High, Medium, Low, from the BIA |
| Control plane flag | Required | Yes if compromise of this service grants control of other services (identity provider, directory, PAM, CI/CD, backup, hypervisor management, MDM, cloud organisation) |
| Data classification | Required | Highest classification of data processed |
| Regulatory scope | Recommended | For example PCI DSS, SOX, NIS2, GDPR personal data |
| Recovery time and point objectives | Required for Critical and High | RTO and RPO agreed with the business owner |
5.2 Any service with the control plane flag set is treated as Critical for administration and identity controls, whatever its business rating.
6. Administration path
6.1 Record how privileged access to the service is obtained and from where. An undocumented admin path is a finding.
| Field | Status | Guidance |
|---|---|---|
| Admin interfaces | Required | Console URLs, SSH, RDP, APIs, cloud control plane, vendor support portal |
| Admin authentication | Required | Identity provider and MFA type; note any local accounts |
| How privilege is granted | Required | Standing role, just-in-time elevation, PAM checkout |
| Permitted source | Required | Privileged access workstation, jump host, management network, pipeline only |
| Admin role holders | Required | Group or role name and current member count; link to access review |
| Break-glass accounts | Required for Critical | Account name, where the credential is held, last test date |
| Third-party admin access | Recommended | Vendor or MSP access route, contract reference, how sessions are approved |
| Privileged runbooks | Recommended | Runbook IDs for privileged tasks. See Privileged Operations Runbooks |
7. Machine identities and secrets
7.1 List every non-human identity the service uses or exposes. The register holds the reference; the identity inventory holds the detail. See the NHI Inventory Reconciliation.
| Field | Status | Guidance |
|---|---|---|
| Service accounts | Required | Account names and directory, purpose, privilege level, owner |
| Workload and cloud identities | Required | Roles, managed identities, Kubernetes service accounts, federated workload identities |
| API keys and tokens | Required | Issued by and to whom, scope, where stored, rotation interval |
| OAuth and SaaS integrations | Required | Connected applications, granted scopes, consenting admin |
| Certificates and keys | Required | TLS, signing and client certificates; issuing CA; expiry; renewal method |
| AI agents | Recommended | Agents acting on the service, their delegated identity and approval gates |
| Secret store | Required | Vault or secrets manager path; "none" is a finding for production |
| Last rotation evidence | Recommended | Date and ticket of last rotation for each credential |
7.2 Every machine identity has a named human owner. An identity with no owner is raised for review within [10 working days]. See the NHI Ownership Guide.
8. Dependencies and data flows
| Field | Status | Guidance |
|---|---|---|
| Upstream dependencies | Required | Services this one needs: identity provider, DNS, database, message queue, payment provider |
| Downstream consumers | Recommended | Services and customers affected if this one fails or is compromised |
| Supporting infrastructure | Recommended | Data centre, power, cloud region, network links |
| Third parties | Required | Suppliers with access or data, with criticality from third-party risk |
| Data flows | Recommended | Link to diagram showing data and authentication flows |
9. Logging, recovery and evidence
| Field | Status | Guidance |
|---|---|---|
| Admin and audit logs | Required | Which logs, where they go (SIEM index), retention |
| Detection coverage | Recommended | Use cases or alerts covering admin actions and machine identity misuse |
| Backup and configuration backup | Required for Critical and High | What is backed up, where, protected how; last restore test date |
| Recovery runbook | Required for Critical | Runbook ID and last exercise date |
| Incident contacts | Required | Who to call, including supplier security contacts |
| Open risks and exceptions | Recommended | Risk register IDs and expiry dates |
10. Maintenance and review
10.1 Technical owners update the record within [5 working days] of any change that alters the admin path, machine identities or dependencies. The change process includes "service register updated" as a closure step.
10.2 Business and technical owners attest each record [every 6 months for Critical and High, annually for others].
10.3 The [Register owner] reconciles the register quarterly against the identity provider application list, the identity inventory, the certificate inventory and cloud accounts, and raises a ticket for every mismatch.
10.4 The register reports these measures each quarter:
| Measure | Calculation | Target |
|---|---|---|
| Required field completeness | Live services with all Required fields complete divided by live services | 100% for Critical, [95%] overall |
| Owner validity | Records whose owners are active employees | 100% |
| Machine identities with owners | Listed identities with a named owner | 100% |
| Documented admin paths | Critical services with a documented, approved admin path | 100% |
| Attestation on time | Records attested by their due date | [90%] |
Implementation guidance
- Start with control planes: Build records for the identity provider, directory, PAM, backup, CI/CD, MDM and cloud organisation first. These are the services whose compromise spreads furthest.
- Use the ITSM service catalogue where you have one: Add the fields in Sections 6 and 7 as attributes on the existing service record rather than starting a parallel list. See the Asset Inventory and CMDB Security Guide.
- Fill machine identities from data, not memory: Pull service principals, service accounts, API keys and certificates from the identity provider, directory, cloud and secrets manager, and ask owners to confirm, rather than asking owners to list them.
- Small organisations: A spreadsheet with one row per service and a tab per section works for up to a few dozen services. Keep it in a restricted location.
- Use it in incidents: Link the Service ID in alerts and incident tickets so responders open the record at the start of triage.
- Framework alignment: NIST CSF 2.0 ID.AM-02 (inventories of software, services and systems), ID.AM-05 (assets prioritised by criticality), GV.OC-05 (dependencies understood) and PR.AA-01 (identities and credentials for users, services and hardware managed); NIST SP 800-53 Rev. 5 CM-8, RA-9 Criticality Analysis, IA-9 Service Identification and Authentication.
Standards and references
- NCSC: Cyber Assessment Framework Principle A3 Asset Management
- NIST: Cybersecurity Framework 2.0
- NIST: SP 800-53 Rev. 5
- NCSC: Secure System Administration
Related NHI Mgmt Group resources: IT Asset Inventory Template · Entitlement Catalogue Guide · IT Operations Security Maturity Model · Designing the IT service catalogue for secure access requests