Account Management Procedure

Account Management Procedure template: The steps, by role, for requesting, approving, creating, changing, disabling, removing and reviewing system accounts, with the inputs, outputs and record each step leaves, that carry out the access control policy's account management requirements (SP 800-53 AC-2), separation of duties (AC-5) and the disabling of access when employment ends (PS-4).

Type	Program stage	Status	Template version	NIST basis
Procedure	Core	Draft	1.0.0	SP 800-53 release 5.2.0

What it is

The steps, by role, for requesting, approving, creating, changing, disabling, removing and reviewing system accounts, with the inputs, outputs and record each step leaves, that carry out the access control policy’s account management requirements (SP 800-53 AC-2), separation of duties (AC-5) and the disabling of access when employment ends (PS-4).

Controls satisfied

Control	Title
AC-2	Account Management
AC-2(1)	Automated System Account Management
AC-2(2)	Automated Temporary and Emergency Account Management
AC-2(3)	Disable Accounts
AC-2(4)	Automated Audit Actions
AC-2(13)	Disable Accounts for High-risk Individuals
AC-5	Separation of Duties
AC-6(7)	Review of User Privileges
PS-4	Personnel Termination

Downloads

Variant	Ready to adopt	Annotated
All baselines	Word · Markdown	Word · Markdown

Preview (annotated)

Guidance

The Access Control policy’s AC-2 statements say what must happen to accounts and who is accountable; this procedure says how, step by step. The AC-2 clause sets AC-2f’s “policy, procedures, prerequisites and criteria” to the policy and this procedure, so an assessor reads the two together and then tests the records this procedure says each step leaves. NIST’s AC-1 discussion warns that restating controls is not a procedure: fill in the tools, queues and time limits you actually use, and delete nothing an assessor will ask about. The typical values are copied from the Access Control policy’s AC-2, AC-2(2), AC-2(3), AC-2(13), AC-5 and AC-6(7) clauses, and the departure time in 5.5 from the Personnel Security policy’s PS-4 clause; keep them in step. One procedure can serve every system that uses the organization’s identity provider. A system with its own application accounts adds a system-specific section 3 and notes any step it does differently.

Owner	Approved by	Version	Effective date
Chief Information Security Officer	Fill in: name and title	Fill in: version	Fill in: date

1. Purpose and scope

This procedure carries out the account management requirements of the Organization name Access Control Policy (AC-2). It applies to every account on every system in the system inventory: user, privileged, service, temporary and emergency accounts, in the identity provider, in operating systems and databases, in applications, and in cloud management consoles.

Accounts are managed through Fill in: automated mechanisms used to support the management of system accounts Typical: the organization’s identity provider and its provisioning workflows wherever the system supports it (AC-2(1)). Where it does not, the account manager follows the same steps by hand and records them in the same places.

2. Roles

Role	Responsibilities in this procedure
Requester	Asks for an account or a change of access, for their own use or for someone they supervise
Supervisor	Confirms the user’s need for access, approves requests, and reports when access is no longer needed or the user’s duties change
System owner	Decides the system’s account types and roles, approves privileged access, assigns account managers, and runs the access review
Fill in: data owner, where different from the system owner	Approves access to the information they own, where the system security plan names one
Account manager	Checks prerequisites, creates, changes, disables and removes accounts, and keeps the records
Human resources office	Reports hires, transfers and departures, and starts the onboarding, transfer and termination checklist
Security operations team	Monitors account use and reports atypical use
Senior privacy official	Sets the conditions for access to personally identifiable information, with the system owner

The System owner records the account managers assigned to each system in the system security plan (AC-2b).

3. Account types

The System owner completes this table for each system, and the account manager creates only the types it allows (AC-2a).

Account type	Allowed?	Owner	Approval	Ends or is reviewed
Individual user	Fill in: yes or no	The user	Fill in: personnel or roles required to approve requests to create accounts Typical: the user’s supervisor, plus the system owner or data owner for privileged roles	Access review; disabled when no longer required
Privileged (administrator)	Fill in: yes or no	The administrator, as a separate account from their user account (AC-6(2))	Supervisor and system owner	Access review; privileges reviewed Fill in: the frequency at which to review the privileges assigned to roles or classes of users Typical: quarterly for privileged roles and at least annually for all other roles
Service or system (non-interactive)	Fill in: yes or no	A named person who answers for it	System owner	Access review; disabled when the service it runs is retired
Temporary	Fill in: yes or no	The user, with the sponsor named on the request	As for an individual user	Automatically disabled at the approved end date (AC-2(2))
Emergency (“break glass”)	Fill in: yes or no	The system owner	System owner, after use	Automatically disabled after the period in step 4.3 (AC-2(2))
Account of last resort	Fill in: yes or no	The system owner	System owner	Access review; credentials held under dual control
Shared or group	Fill in: typical: prohibited unless the system owner approves an exception	A named person who answers for it	System owner, as an exception	Authenticators changed whenever a member leaves (step 7)
Guest or anonymous	Fill in: typical: prohibited, except on systems designed for public access	Not applicable	Not applicable	Not applicable

For each account, the account manager records the authorized user, group and role membership, access authorizations and Fill in: attributes (as required) for each account Typical: an expiration date for temporary accounts, and time-of-day or location restrictions where the system supports them (AC-2d).

Guidance

NIST’s AC-2 discussion lists individual, shared, group, system, guest, anonymous, emergency, developer, temporary and service accounts as examples, and names shared, group, emergency, anonymous, temporary and guest accounts as types organizations may prohibit because of their risk. It also separates emergency accounts, which may bypass the normal authorization steps in a crisis and are short-lived, from accounts of last resort, such as local logon accounts used when network resources are unavailable, which stay available and are not subject to automatic disabling. Record any account of last resort here so the inactivity rule in step 5 does not disable it, and the access review still covers it.

4. Prerequisites, criteria and separation of duties

Group and role membership is granted only after Fill in: prerequisites and criteria for group and role membership Typical: a completed access request, a signed access agreement and completed security awareness training (AC-2c). Access is authorized only on a valid access authorization, the intended system usage and the conditions the system owner sets for the role (AC-2i). Where an account will reach personally identifiable information, the conditions for that role are set with the Senior privacy official.

The System owner identifies and documents these duties of individuals that require separation: Fill in: duties of individuals requiring separation Typical: requesting and approving access; developing and deploying code to production; administering a system and reviewing its audit logs (AC-5a). They are held by different people, and the system’s roles are designed so no single account holds both sides (AC-5b):

Duty	Separated from	How the system enforces it
Requesting access	Approving the same access	Fill in: for example the request tool blocks self-approval
Approving access	Granting it in the system	Fill in: for example account managers cannot approve; approvers have no administrative role
Administering the system	Reviewing or deleting its audit logs	Fill in: for example logs sent to a platform administrators cannot change
Developing code	Deploying it to production	Fill in: for example the pipeline requires an approving review by someone other than the author
Fill in: other duty the system owner names	Fill in: duty	Fill in: how

5. Procedures

Each step names the role that performs it, what it starts from, what it produces, and the record it leaves. The records are the evidence an assessor samples.

5.1 Request and approve an account or a change of access

#	Role	Action	Inputs	Outputs	Record
1	Requester	Submit an access request naming the user, system, account type, roles and the business need; for a temporary account, the end date	Need for access	Submitted request	Access request, with its date
2	Account manager	Check the prerequisites in section 4 are met: Fill in: prerequisites and criteria for group and role membership Typical: a completed access request, a signed access agreement and completed security awareness training	Request; access agreement register; training records	Request ready for approval, or returned with what is missing	Prerequisite check on the request
3	Account manager	Check the requested roles against section 4 and the user’s other roles for separation of duties conflicts	Request; the user’s current roles	Conflicts listed, or none	Conflict check on the request
4	Fill in: personnel or roles required to approve requests to create accounts Typical: the user’s supervisor, plus the system owner or data owner for privileged roles	Approve or reject each role requested. The approver is not the requester, and approves no more than the duties need (AC-6)	Request; conflict check	Approved or rejected request	Approver name and date on the request

5.2 Create the account and grant access

#	Role	Action	Inputs	Outputs	Record
1	Account manager	Create or enable the account only after the approval in 5.1 step 4 (AC-2e), with the type, groups and roles approved, and the attributes in section 3	Approved request	Account in the identity provider or system	Provisioning record linked to the request; the system’s audit record of the creation (AC-2(4))
2	Account manager	Issue the initial authenticator through the process the identification and authentication policy sets, as section 9 of the identification and authentication standard describes (IA-5)	Account	Authenticator delivered to the user	Issuance record
3	Account manager	Close the request, noting the account identifier and the date	Provisioning record	Closed request	Access request, Part F

5.3 Temporary and emergency accounts

#	Role	Action	Inputs	Outputs	Record
1	Account manager	Create a temporary account through 5.1 and 5.2, with the approved end date set so the system takes this action automatically at that date: Select one: remove; disable Typical: disable (AC-2(2))	Approved request with an end date	Temporary account with an end date	Request; end date in the account record
2	System owner	In a crisis, enable an emergency account without the full approval in 5.1, and tell Security operations team it is in use	Declared emergency	Emergency account in use; alert raised	Ticket or incident record naming who used it and why
3	Account manager	Ensure the system takes this action automatically on the emergency account: Select one: remove; disable Typical: disable, after Fill in: the time period after which to automatically remove or disable temporary or emergency accounts Typical: 72 hours for emergency accounts, and the end date approved at creation for temporary accounts (AC-2(2)); change its credentials after each use	Emergency account	Account disabled; credentials changed	Audit records of the disabling and the credential change
4	System owner	Review each use of an emergency account within Fill in: for example 5 business days, and record approval after the fact or report misuse as an incident	Audit records of the session	Review result	Review note on the ticket

5.4 Change access

#	Role	Action	Inputs	Outputs	Record
1	Supervisor	Notify the account manager and Fill in: personnel or roles to be notified Typical: the system owner and the system security officer within Fill in: time period within which to notify account managers when system usage or the need to know changes for an individual Typical: 5 business days when a user’s system usage or need to know changes (AC-2h.3)	Change in duties	Notice	Notice, dated
2	Human resources office	Notify the account manager and Fill in: personnel or roles to be notified Typical: the system owner and the system security officer within Fill in: time period within which to notify account managers when users are terminated or transferred Typical: 24 hours, or the same day for privileged users when a user transfers (AC-2h.2), through the transfer section of the onboarding, transfer and termination checklist	Approved transfer	Notice; checklist started	Checklist, dated
3	Account manager	Remove the access the user no longer needs, and grant new access only through 5.1 and 5.2	Notice; new access request	Account changed	Audit record of the modification (AC-2(4)); request

5.5 Disable and remove accounts

#	Role	Action	Inputs	Outputs	Record
1	Supervisor	Notify the account manager and Fill in: personnel or roles to be notified Typical: the system owner and the system security officer within Fill in: time period within which to notify account managers when accounts are no longer required Typical: 5 business days when a user’s account is no longer required (AC-2h.1)	End of need	Notice	Notice, dated
2	Human resources office	Notify the account manager and Fill in: personnel or roles to be notified Typical: the system owner and the system security officer within Fill in: time period within which to notify account managers when users are terminated or transferred Typical: 24 hours, or the same day for privileged users when a user is terminated (AC-2h.2), through the termination section of the checklist	Approved departure	Notice; checklist started	Checklist, dated
3	Account manager	When a user’s employment ends, disable all of their system access within Fill in: a time period within which to disable system access Typical: 24 hours, or the same day for privileged users; for an involuntary termination, no later than when the individual is told of the termination, and revoke their authenticators and credentials, as steps 2 and 3 of the termination section of the onboarding, transfer and termination checklist set out (PS-4a, PS-4b)	Notice; checklist	Access disabled; authenticators and credentials revoked	Audit record of the disabling, dated; checklist steps 2 and 3, dated
4	Account manager	Disable the account within Fill in: time period within which to disable accounts Typical: 1 business day when it has expired, is no longer associated with a user for a reason other than a departure under step 3, or is in violation of policy (AC-2(3))	Notice; review finding; expiry	Account disabled	Audit record of the disabling, dated
5	Account manager	Confirm the system disables accounts inactive for Fill in: time period for account inactivity before disabling Typical: 90 days, other than accounts of last resort listed in section 3 (AC-2(3)(d))	System setting	Inactive accounts disabled	Setting, checked at each access review
6	Account manager	On notice of Fill in: significant risks leading to disabling accounts Typical: credible indicators of insider threat, or notice of an adverse personnel action, disable all of the individual’s accounts within Fill in: time period within which to disable accounts of individuals who are discovered to pose significant risk Typical: 1 hour of discovery (AC-2(13))	Notice from the Human resources office, Security operations team or the insider threat program	Accounts disabled	Audit records; case reference
7	Account manager	Remove a disabled account after Fill in: for example 30 days, once the supervisor has moved any files the organization needs, unless a legal hold or investigation requires it be kept	Disabled account	Account removed	Audit record of the removal

5.6 Shared and group accounts

#	Role	Action	Inputs	Outputs	Record
1	Account manager	Keep a list of the members of each approved shared or group account	Exception approval	Member list	List, with the date of each change
2	Account manager	Change the account’s authenticators when a member is removed from the group, within the time set for disabling accounts in 5.5 (AC-2k)	Notice that a member left	New authenticator, given only to remaining members	Audit record of the change; member list

If the system has no shared or group accounts, the system security plan says so.

5.7 Monitor account use

#	Role	Action	Inputs	Outputs	Record
1	Security operations team	Monitor account use for activity that does not fit the account’s type or authorization, such as logons at unusual times or places, use of dormant accounts, or interactive use of service accounts (AC-2g)	Audit records of account use	Alerts	Alert records
2	Security operations team	Report atypical use to the System owner, and handle any suspected incident under the incident response plan	Alert	Report; incident, where needed	Ticket or incident record

5.8 Review accounts

#	Role	Action	Inputs	Outputs	Record
1	Account manager	Export the full account list for the system, including service, emergency and application-local accounts, with roles and last logon	Identity provider and system	Account list, dated	Export attached to the access review record
2	System owner	Review every account Fill in: the frequency of account review Typical: quarterly for privileged accounts and at least annually for all other accounts for compliance with the policy and this procedure, and review the privileges assigned to Fill in: roles or classes of users to which privileges are assigned Typical: all roles and classes of users on the system, Fill in: the frequency at which to review the privileges assigned to roles or classes of users Typical: quarterly for privileged roles and at least annually for all other roles (AC-2j, AC-6(7)(a))	Account list; supervisors’ confirmations	A decision for each account: keep, change, disable or remove	Access review record
3	Account manager	Disable or remove each account, and remove each privilege, the review finds is not needed, within Fill in: for example 5 business days (AC-2j, AC-6(7)(b))	Review decisions	Accounts and privileges changed	Ticket per action, referenced in the review record
4	System owner	Sign off the review once every action is done	Completed actions	Signed review	Access review record and its register row

6. Records

Record	Kept in	Retention
Access requests and approvals	Fill in: for example the service management tool	Fill in: for example the life of the account plus 3 years
Account change audit records (AC-2(4))	Fill in: for example the log platform	As the audit logging standard sets (AU-11)
Onboarding, transfer and termination checklists	Fill in: location	Fill in: period
Emergency account use reviews	Fill in: location	Fill in: period
Access review records	Fill in: location	Fill in: for example 3 years, or at least until the next assessment

7. Review

The Chief Information Security Officer reviews this procedure Fill in: for example annually, and after assessment or audit findings, security incidents, and changes to the identity provider, access governance tool or personnel processes.

Version	Date	Change	Approved by
Fill in: version	Fill in: date	Fill in: summary of change	Fill in: name and title