Laws, frameworks and account access

What internal audit should check about accounts

Use NIST SP 800-53A's procedure for account management (AC-2). Examine account lists against HR and approval records, interview admins, and test removal.

Updated October 16, 2026

A good place to start is the assessment procedure for account management (AC-2) in NIST SP 800-53A Rev. 5. It turns the control into statements to confirm, such as “approvals are required” before accounts are created. For each control it lists the methods to use, and for AC-2 there are three: examine records, interview people, and test the mechanism. For accounts, the main evidence is an account list pulled from each app, compared with HR records and approval records.

How 800-53A is organized

NIST SP 800-53A is the companion to SP 800-53 Rev. 5, the federal government’s control catalog. It’s written for federal systems, but NIST says nongovernmental organizations may use it voluntarily. Each control has an assessment objective, a list of “determine if” statements, and potential methods and objects.

The three methods are defined this way. To examine is to review, inspect, observe, study or analyze documents, mechanisms or activities. To interview is to hold discussions with people to understand, clarify or obtain evidence. To test is to exercise a mechanism or activity under set conditions and compare what happens with what should happen.

You don’t have to use every method or object. 800-53A says organizations decide the level of effort and assurance each assessment needs. It describes that effort as depth (how rigorous) and coverage (how many items and people), each set at basic, focused or comprehensive.

Settle the definitions before you audit

AC-2 leaves several values to your organization. Who approves new accounts? How soon must account managers hear that someone left or moved? How often are accounts reviewed? Under what conditions may a shared account exist? In 800-53A, the procedures for AC-2 and AC-2(9) open by asking whether these values are defined. If your policy is silent on them, that’s the first finding, and the later checks have nothing to measure against.

Checklist for an account audit

The control letters refer to AC-2 in SP 800-53 Rev. 5. The objects come from the lists 800-53A gives for each procedure.

Get a current account list from each app in scope

You need every active account and the person behind each one. Note the date and time you pulled it, because the list changes daily.

Source

AC-2d asks that authorized users and each account’s access be specified. 800-53A lists “list of active system accounts along with the name of the individual associated with each account” among the objects to examine.

How to check

Examine. Pull the list from the app’s admin screen yourself, or watch it being pulled, rather than accepting a spreadsheet.
Check that access was approved before it was granted

Pick accounts created or changed during the audit period.

Source

AC-2e requires approval by the people your policy names for requests to create accounts.

How to check

Examine access authorization records. Compare each approval date with the date the account was created.
Compare leavers and movers with disabled accounts

Take HR’s list of people who left or changed jobs in the period. Find each one in the app’s account list.

Source

AC-2h asks that account managers be told within your defined time when users leave or move. AC-2l asks that account management line up with HR’s termination and transfer processes.

How to check

Examine notices of recent separations and transfers next to the list of recently disabled accounts. Compare each disable date with the last day and your defined time.
Look for expired and inactive accounts

Accounts nobody uses are easy to miss in a leaver check.

Source

AC-2(3) asks that accounts be disabled within your defined time when they expire, no longer belong to a person, break policy, or sit inactive too long.

How to check

Examine the system-generated list of removed accounts. Sort the active list by last sign-in.
Review every shared account

For each one, find the reason it exists and the people allowed to use it.

Source

AC-2(9) allows shared accounts only under conditions you define. AC-2k asks for a process to change a shared account’s password when someone leaves the group.

How to check

Examine the list of shared accounts and their roles. For each one, compare the last password change with the departure dates of people who knew it.
Confirm the periodic reviews happened

A review counts only if it left a record.

Source

AC-2j asks that accounts be reviewed against your account management rules at your defined frequency.

How to check

Examine account management review records: who reviewed, the date, and what was removed as a result.
Check that use can be traced to a person

Monitoring helps only if the log names the person.

Source

AC-2g asks that the use of accounts be monitored. The objects to examine include system monitoring records and audit records.

How to check

Examine a sample of sign-in records for each app. For shared accounts, note that the log shows the account name, and ask what other record shows who used it.
Test that removal works

A disabled account should not be able to sign in.

Source

800-53A lists the mechanisms for account management as the object to test.

How to check

Test. With the admin, disable a test account and confirm sign-in fails, or confirm a recent leaver’s account can’t sign in.

Who to interview

800-53A suggests the people with account management duties, system and network administrators, and security staff. Interviews explain how the process is supposed to run and point you to the records. Examining those records and testing the mechanism then show whether it ran that way.

How to record the results

800-53A rates each statement one of two ways: “satisfied” or “other than satisfied”. The second can also mean you couldn’t get enough information to decide. For each finding of that kind, say which part of the control is affected and how the actual state differs from what was expected. You may add your own severity levels to help set priorities.

Keep the lists you pulled with the date and time, alongside the notes from interviews and tests. Without the list as it was on the day, nobody can repeat your comparison later.

What a public company’s outside auditor tests for SOX is a narrower question, covered in How auditors test user access controls in a SOX audit.

Frequently asked questions

Do we have to follow NIST SP 800-53A?

No. NIST says nongovernmental organizations may use it on a voluntary basis. It works as a ready-made set of questions and evidence lists for account controls.

Is interviewing the IT admin enough?

800-53A leaves the choice of methods to you, based on the assurance you need. For a control you rely on, examining records and testing the mechanism show what actually happened.

How often should accounts be reviewed?

AC-2 leaves the frequency to your organization. Set it in your policy, then audit against what the policy says.

How should a finding be written?

800-53A rates each statement satisfied or other than satisfied. For the second, say which part of the control is affected and how the actual state differs from what was expected.

How Junify handles this

Doing this by hand: You map each requirement to how your team actually works. You keep a record an auditor can review: which accounts exist, who may use each one, and who used it. And you reread the rules each time they change.
With Junify: Shared logins are where account audits stall, because the app's log shows one name for several people. For the accounts you add to Junify, each person verifies on their own phone before Junify fills in the login, so each use is recorded by person and time. The list of who may use each account and the sign-in record export as CSV, which gives the auditor something to compare against HR records.

Try the demo Book a 30-minute demo