What a SOX audit asks about admin accounts, and which records to keep

Under the Sarbanes-Oxley Act (SOX), a public company’s management reports each year on whether its internal control over financial reporting works. Admin accounts come up because they can change the systems those controls run on. What you need to show is who holds admin rights in those systems and who used them, with records to back it up.

Where admin accounts come into the assessment

Section 404(a) of SOX (15 U.S.C. 7262) directs the SEC to require an assessment by management in each annual report. It covers “the effectiveness of the internal control structure and procedures of the issuer for financial reporting.” Under section 404(b), the company’s outside auditor attests to that assessment. Section 404(c) exempts companies that are neither large accelerated filers nor accelerated filers from the auditor’s part, and emerging growth companies are also left out of 404(b). Management’s own assessment applies either way.

The outside auditor follows Auditing Standard No. 5 (now AS 2201) from the Public Company Accounting Oversight Board (PCAOB). It tells the auditor to “understand how IT affects the company’s flow of transactions” (paragraph 36). Among the factors that affect a control’s risk, it lists how far the control relies on other controls, such as “information technology general controls” (paragraph 47). The same paragraph says an automated control is generally lower risk if the related IT general controls are effective.

The SEC’s 2007 guidance for management (Release No. 33-8810) explains where IT fits. Many controls over financial reporting are automated or depend on software. The guidance says those controls often work properly only if the IT general controls around the software work. Management needs to evaluate only the IT general controls that matter for that. As example areas, it names “program development, program changes, computer operations, and access to programs and data.”

Admin accounts belong to the last area. An admin in your accounting or billing system can change users, settings and data. So an admin account nobody keeps track of can undo the automated controls that management’s assessment relies on.

Access comes up again in the appendix to AS 2201. Paragraph B29 lets the auditor rely on last year’s test of an automated control without repeating it. That holds only if the control hasn’t changed and “general controls over program changes, access to programs, and computer operations” are effective and still tested. If access to programs isn’t controlled, that shortcut isn’t available.

What counts as evidence

Management must keep evidence that gives “reasonable support” for its assessment. The SEC guidance describes two kinds. Direct tests are done from time to time by people with a high degree of objectivity about the control. Ongoing monitoring is the company’s routine checking, including self-assessment. When the people who run a control assess it themselves, that evidence counts for less, because they’re less objective.

Where the risk is high, the evidence ordinarily comes from direct testing, or from monitoring by more objective people. Whatever the risk, management’s evaluation ordinarily considers evidence from a reasonable period of the year, including fiscal year-end.

For admin accounts, two things follow. An admin’s word that only the right people have access isn’t evidence on its own; a dated list and a log are. And the person who reviews admin access shouldn’t be one of the admins.

Four records to keep for admin accounts

Neither the statute nor the SEC guidance lists specific records. These four answer what an access review asks. Each one lines up with a control in NIST SP 800-53 Rev. 5, the federal government’s security control catalog. NIST isn’t a SOX rule, and it serves here only as a checklist.

1. A list of admin accounts. For each system in scope, which admin accounts exist and who holds each. NIST AC-2(7) asks you to monitor privileged role assignments. CIS Controls safeguard 5.1 says an account inventory must include administrator accounts.
2. Records of granting and removing admin rights. Who got or lost the rights, when, and who approved it. AC-2(7) also asks you to revoke access when a privileged role is no longer appropriate.
3. Logs of use. When each admin account was used, by whom, and what it did. AC-6(9) asks you to log the use of privileged functions.
4. Periodic reviews. When someone checked that each admin still needs the rights, who checked, and what changed. AC-6(7) asks you to review privileges at a frequency you set, to confirm they’re still needed.

What belongs in a log of use is covered in What records to keep for privileged account audits.

Where shared admin logins fall short

When several people use one admin login, two of the four records come out incomplete. The system’s log shows the account name, not the person, so the log of use has no answer for “by whom.” The record of granting and removing rights turns into a record of who was told the password. A person who left may still remember it, and nothing in the records shows that.

NIST AC-2(9) asks you to weigh the “lack of accountability” of shared accounts before allowing them. Ways to keep a shared admin login while recording who used it are laid out in Managing privileged accounts.

Which systems are in scope

The SEC guidance says it’s unnecessary to evaluate IT general controls that mainly serve efficiency and don’t address financial reporting risks. So the admin accounts in scope are the ones on systems your financial reporting controls run on or depend on. The guidance doesn’t name cloud services, but it covers processes a company hands to a service organization. Management may need evidence that the provider’s controls work, such as a service auditor’s report. AS 2201 has the auditor include such a provider’s activities when its service is part of the company’s information system (paragraphs B17 and B18). So the admin console of a SaaS financial system can be in scope; confirm the scope with your auditor.