Service Account Request Form Template

Most service account problems start on the day the account is created, when nobody records who owns it, what it is for, what it may reach or when it should end. A request form fixes that at the front door: no account exists until an owner, a purpose, a scope, a credential type and an expiry date have been written down and approved. This template gives you a ready-to-use service account request form with field-by-field guidance, an approval route by risk tier and the checks the provisioning team runs before creating anything. It is for IAM, platform and security teams who run service account provisioning in Active Directory, Microsoft Entra ID, cloud platforms or SaaS. The record it produces feeds the Service Account Inventory Template, and the controls around it are in the Service Account Security Guide.

How to use this template

Replace text in square brackets, such as [Organisation], [IAM team] and [12 months], with your own teams, systems and values. Values in brackets are NHI Mgmt Group suggestions, not requirements of any standard.
Section 3 is the form itself. Each field becomes a field in your ITSM or IGA request catalogue item. Fields marked "Required" block submission when empty.
Field names deliberately match the record fields in the Service Account Inventory Template, so an approved request becomes an inventory record without retyping.
Use one form for every platform. Platform-specific details (account type, credential type) are choices inside the form, not separate forms, so the approval rules stay consistent.
The fields follow the information Microsoft lists for governing service accounts (owner, purpose, permissions, CMDB links, risk and anticipated lifetime) and the account management controls in NIST SP 800-53 Rev. 5 AC-2 and IA-4.

1. Purpose

This form is the only approved route for creating a service account, workload identity or other non-human account at [Organisation]. Its purpose is to make sure that every such account has an accountable owner, a documented purpose, the least privilege needed, an approved credential type and a review or expiry date before it is created. Accounts created outside this process are treated as unregistered and are subject to review and disablement under section 7.

2. Scope

This form covers requests to create, materially change or extend any of the following:

Active Directory user accounts used by services, standalone and group managed service accounts (sMSA, gMSA) and delegated managed service accounts (dMSA, introduced in Windows Server 2025).
Microsoft Entra ID service principals, application registrations and managed identities.
Cloud workload identities: AWS IAM roles and IAM users with access keys, Google Cloud service accounts, Azure managed identities.
Kubernetes service accounts with access beyond their own namespace.
SaaS integration users, API keys and OAuth clients that act on behalf of an application rather than a person.
Accounts created for AI agents and automation tools.

Out of scope: accounts for named people (use the standard joiner process) and emergency break-glass accounts (use the Break Glass Access Procedure Template).

3. Request form fields

3.1 Requester and ownership

Field	Required	Guidance
Requester	Yes	Named person submitting the request.
Business owner	Yes	A named employee accountable for the account's existence and use. Not a shared mailbox, not a contractor whose engagement ends sooner than the account.
Technical owner	Yes	Named person or team who maintains the application and handles credential rotation.
Deputy owner	Yes for High risk	Takes over when the owner leaves or moves, so the account is not orphaned.
Cost centre or team	Yes	Used to reassign ownership when people change.

3.2 Purpose and usage

Field	Required	Guidance
Purpose	Yes	One or two sentences: what the account does and why a person's account cannot be used. Reject "for the application" or "general automation".
Application or service	Yes	CMDB configuration item (CI) the account belongs to. One account, one application.
Where it runs	Yes	Hostnames, clusters, pipelines or SaaS tenant the account will authenticate from.
Environment	Yes	Production, pre-production, test or development. One account per environment; never share a production account with test.
Interactive use needed?	Yes	Default No. If Yes, explain why; the expected answer is a separate human account through privileged access instead.
Expected activity	Recommended	Times, volumes and targets (for example "nightly 02:00, reads HR database, writes to file share"). Used later to build a behavioural baseline.

3.3 Account and credential type

Field	Required	Allowed values
Platform	Yes	[Active Directory] · [Microsoft Entra ID] · [AWS] · [Azure] · [Google Cloud] · [Kubernetes] · [SaaS: name]
Account type	Yes	Managed identity or federated workload identity · gMSA or dMSA · IAM role · cloud service account without keys · user account used as a service account (exception only)
Credential type	Yes	Platform-managed (no secret held by people) · certificate · secret or key in [vault] · static password (exception only)
Credential location	Yes if a secret exists	Vault path or secrets manager reference. Never a file path, script, ticket or wiki page.
Rotation method	Yes if a secret exists	Automatic by platform · automatic by vault · manual with runbook. Manual rotation needs an exception.
Justification for long-lived secret	If credential is a static key or password	Why a managed or federated identity cannot be used, with a target date to move off it.

The order of preference reflects vendor guidance: Microsoft does not recommend on-premises user accounts as service accounts and suggests assessing gMSA or sMSA instead; AWS recommends that workloads use temporary credentials through IAM roles; Google Cloud recommends avoiding service account keys whenever possible. See the Workload Identity Federation Guide.

3.4 Access scope

Field	Required	Guidance
Target systems and resources	Yes	List each system, database, bucket, API or subscription. "All" is not accepted.
Permissions requested	Yes	Named roles, groups or API scopes per target. Prefer built-in narrow roles or a custom role over Owner, Editor, Contributor or Domain Admins.
Privileged group membership	Yes (Yes/No)	Any tier 0 or administrative group, or cloud organisation-level role, makes the request High risk automatically.
Data classification reached	Yes	Highest classification of data the account can read or change (for example [Public], [Internal], [Confidential], [Restricted]).
Network restrictions	Recommended	Source hosts or IP ranges allowed to use the account; logon workstation restrictions for AD accounts.
Who can impersonate or manage it	Yes for cloud	People or groups allowed to act as, or change the access policy of, this identity. Should not exceed their own privilege.

3.5 Lifetime and review

Field	Required	Guidance
Expiry or recertification date	Yes	Date the account expires unless the owner recertifies it. NHI Mgmt Group suggests no more than [12 months] for Low and Medium risk and [6 months] for High risk.
Review cycle	Yes	Set from the risk tier in section 4.
Decommission trigger	Recommended	Event that ends the account, such as application retirement or contract end.
Dependencies	Recommended	Jobs or services that will fail if the account is disabled. Needed for safe rotation and removal.

4. Risk tier and approval route

The provisioning team assigns the tier from the answers in section 3. The highest matching row applies.

Tier	Triggers (any one)	Approvers	Review cycle (our suggestion)
High	Privileged group or organisation-level role; Restricted data; static password or long-lived key in production; interactive use requested; access to identity systems	Business owner, [IAM lead] and [Security architecture]	[Every 6 months]
Medium	Confidential data; write access to production; secret held in a vault; access across more than one application	Business owner and [IAM lead]	[Every 12 months]
Low	Platform-managed credential; read-only access to Internal data; non-production only	Business owner	[Every 12 months] or at expiry

The requester cannot approve their own request. An approver who is also the owner counts once. For approval design and rubber-stamping risks, see the Access Request and Approval Workflow Design Guide.

5. Provisioning checks

Before creating the account, [IAM team] confirms:

All Required fields are complete and the owner is an active employee.
No existing account already serves this application and environment (search the inventory first; reuse across applications is not allowed).
The account type and credential type are the most preferred option the platform supports, or an approved exception is attached.
Permissions match the request exactly; no "temporary" broad role is granted to "get it working".
For AD user accounts used as services: interactive sign-in is denied (for example the Deny log on locally user right), logon workstations are restricted where the service runs locally, and an account expiry date is set.
For cloud identities: key creation is blocked where the platform allows it, and impersonation rights match section 3.4.
The account name follows [naming convention] and the description field holds the owner and the request reference, with no sensitive information in the name.
The inventory record is created at the same time as the account, with status "Active" and the request number.

6. Changes, extensions and removal

Permission changes: any added permission, new target or move to a higher tier needs a new request referencing the original.
Extensions: the owner recertifies before the expiry date by confirming purpose, scope and dependencies. If nobody recertifies, the account is disabled at expiry, not deleted.
Owner change: when the owner leaves or changes role, ownership passes to the deputy within [10 working days] or the account enters the orphan review in section 7.
Removal: disable first, hold for [30 days], then delete. Google Cloud notes that deleting and recreating a service account with the same name creates a new identity, so original bindings no longer apply; disabling keeps them. See the NHI Offboarding and Decommissioning Guide.

7. Exceptions and unregistered accounts

Exceptions (static passwords, interactive use, privileged groups without a managed alternative) are approved by [CISO or delegate], recorded with an end date of no more than [12 months] and listed in the risk register.
Accounts found by discovery with no matching request are flagged as unregistered. The owning team has [30 days] to submit a retrospective request; otherwise the account is restricted and then disabled after notice.

8. Records

Keep the request, approvals, provisioning check results and later changes for [the life of the account plus 2 years] so auditors can trace every account back to an approved purpose.

Implementation guidance

Build it into the catalogue: publish the form as one ITSM or IGA catalogue item with conditional fields per platform. Make Required fields mandatory in the tool, not in a policy document.
Close the side doors: the form only works if accounts cannot be created another way. Restrict who can create AD users in service account OUs, who can register applications in Entra ID, and who holds service account admin roles in cloud projects. Alert on creations with no request number.
Start with new requests: apply the form to all new accounts from day one, then use the Service Account Inventory Template and How to Run an Access Review for Service Accounts to bring existing accounts in line.
Small and large organisations: a small team can run this as a shared form with an email approval and a spreadsheet. A large organisation should drive provisioning from the approved request automatically, so the account, vault entry and inventory record are created together.
Measure it: track the percentage of service accounts with a request reference, the percentage with a named active owner, the count of static secrets approved as exceptions, and requests rejected or reduced in scope at approval.

Form section	NIST SP 800-53 Rev. 5	NIST CSF 2.0	OWASP NHI Top 10 2025
3.1 Ownership, 6 Owner change	AC-2 Account Management	PR.AA-01	NHI1 Improper Offboarding
3.2 Purpose, environment, interactive use	AC-2, IA-4 Identifier Management	PR.AA-01	NHI8 Environment Isolation, NHI9 NHI Reuse, NHI10 Human Use of NHI
3.3 Credential type and rotation	IA-5 Authenticator Management	PR.AA-01	NHI7 Long-Lived Secrets
3.4 Access scope	AC-6 Least Privilege	PR.AA-05	NHI5 Overprivileged NHI
3.5 Expiry, 6 Removal	AC-2(3) Disable Accounts	PR.AA-05	NHI1 Improper Offboarding

Service Account Request Form Template: Purpose, Owner, Scope and Expiry Fields