# 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.

{: .checklist}
1. **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.

2. **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.

3. **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.

4. **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.

5. **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.

6. **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.

7. **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.

8. **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](/guides/compliance/sox-itgc-user-access-testing).


## 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.

## Sources

- [NIST SP 800-53A Rev. 5, Assessing Security and Privacy Controls in Information Systems and Organizations (January 2022)](https://nvlpubs.nist.gov/nistpubs/SpecialPublications/NIST.SP.800-53Ar5.pdf)
- [NIST SP 800-53 Rev. 5, Security and Privacy Controls for Information Systems and Organizations (AC-2)](https://nvlpubs.nist.gov/nistpubs/SpecialPublications/NIST.SP.800-53r5.pdf)

## 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.

Junify is an access management service for handing work in your web accounts to employees, contractors and outside teams without giving them the password. Each person verifies on their own phone and clicks a card to sign in. The password is never shown, and Junify records who used which account and when.

- [Try the demo](https://www.junify.com/bpo/try?lang=en&from=guide&cluster=compliance&slug=internal-audit-account-checklist)
- [Book a 30-minute demo](https://www.junify.com/bpo/demo)

## More on this topic

- [What access logs need to show when you decide whether to report a breach](/guides/compliance/breach-notification-access-logs): Logs show whether data was viewed, by whom, for how many people and since when. HIPAA presumes a breach unless you can show a low probability of compromise.
- [Password sharing and the federal anti-hacking law (CFAA)](/guides/compliance/cfaa-password-sharing): The CFAA turns on whether the system's owner allowed the access. In Nosal, former employees using a current employee's login acted without authorization.
- [What CIS Controls 5 and 6 (v8.1) ask of your accounts](/guides/compliance/cis-controls-account-access-management): Control 5 asks for an account inventory, disabled dormant accounts and separate admin accounts. Control 6 covers granting and revoking access, and MFA.
