IRS Logo
Print - Click this link to Print this page

Auditing Controls of Federal Tax Information

Request for Technical Assistance

An agency is currently in the process of replacing its integrated tax system. FTI will continue to be retrieved from the TDS and other means based on business needs for other audit programs and other divisions, as not all of the FTI used for State tax purposes will be in the data warehouse. 

  1. What the requirements for tracking and recording FTI will be for DOR users who access FTI for State tax purposes from the data warehouse.
  2. I would appreciate your thoughts on tracking FTI received and relying on the audit logs to track user access and viewing of the FTI.


IRS Publication 1075 outlines the requirements and guidelines to ensure that FTI is properly audited.  Specifically section 5.6.2 and exhibit 9.

An audit trail or audit log is a chronological sequence of audit records (otherwise known as audit events), each of which contains evidence directly pertaining to and resulting from the execution of a business process or system function.  Audit records should be generated when subjects (e.g. system users or automated processes) perform business related activities with system resources (e.g. files, database objects).  Audit records should also be produced when adversaries try to perform unauthorized activities on the system resources. Each audit record captures the details related to the underlying event e.g.:

  • Date and time of the event;
  • Unique ID of the user;
  • Type of event;
  • Success or failure of event;
  • Origin of the request;
  • Name of the object introduced/deleted; and
  • Description of modification to security databases.

Ultimately, for the purposes of safeguarding FTI, the audit trail (captured at various layers – network, system, and application) should be comprehensive enough by capturing security related events occurring on the system to historically recreate the sequence of events leading to successful and unsuccessful access attempts to FTI.  The evidence provided by an audit trail can assist an agency with correlating a sequence of events that answer questions such as:  Has an unauthorized access to FTI occurred?  Was that particular user authorized to have access to FTI?  Did they have a need-to-know at the time to gain access to FTI?  Was the FTI altered in any way?  Did the FTI leave the system?  Was FTI disclosed? 

Exhibit 9 in Publication 1075 identifies the system audit management guidelines which identifies specifically the types of events, transactions and details needed to be captured for a complete audit trail.

  1. The audit trail shall capture all successful login and logoff attempts.
  2. The audit trail shall capture all unsuccessful login and authorization attempts.
  3. The audit trail shall capture all identification and authentication attempts.
  4. The audit trail shall capture all actions, connections and requests performed by privileged users (a user who, by virtue of function, and/or seniority, has been allocated powers within the computer system, which are significantly greater than those available to the majority of users. Such persons will include, for example, the system administrator(s) and network administrator(s) who are responsible for keeping the system available and may need powers to create new user profiles as well as add to or amend the powers and access rights of existing users).
  5. The audit trail shall capture all actions, connections and requests performed by privileged functions.
  6. The audit trail shall capture all changes to logical access control authorities (e.g., rights, permissions).
  7. The audit trail shall capture all system changes with the potential to compromise the integrity of audit policy configurations, security policy configurations and audit record generation services.
  8. The audit trail shall capture the creation, modification and deletion of objects including files, directories and user accounts.
  9. The audit trail shall capture the creation, modification and deletion of user accounts and group accounts.
  10. The audit trail shall capture the creation, modification and deletion of user account and group account privileges.
  11. The audit trail shall capture: i) the date of the system event; ii) the time of the system event; iii) the type of system event initiated; and iv) the user account, system account, service or process responsible for initiating the system event.
  12. The audit trail shall capture system start-up and shutdown functions.
  13. The audit trail shall capture modifications to administrator account(s) and administrator group account(s) including: i) escalation of user account privileges commensurate with administrator-equivalent account(s); and ii) adding or deleting users from the administrator group account(s).
  14. The audit trail shall capture the enabling or disabling of audit report generation services.
  15. The audit trail shall capture command line changes, batch file changes and queries made to the system (e.g., operating system, application, and database).
  16. The audit trail shall be protected from unauthorized access, use, deletion or modification.
  17. The audit trail shall be restricted to personnel routinely responsible for performing security audit functions.

The need and ability to perform auditing has been around for some time.  Therefore, virtually all reputable vendors build auditing features into their operating systems, databases, and applications.  Unfortunately, many of these features are typically disabled by default because many feel the processing of auditing activities carries with it system performance degradation.  If planned and implemented wisely, the performance impact can be minimized by enabling the right auditing at the appropriate layers.

IRS requires any and all operating systems, databases, and applications that receive, store, process and/or transmit FTI to enable their auditing features with respect to the actual FTI data. The agency should implement and adhere to a sensible auditing policy so that legitimate users are held accountable for their actions and unauthorized activity is detected and tracked. If no auditing is configured, or if the auditing is set too low, sufficient evidence will not be captured detect security violations and conduct analysis after security incidents. On the other hand, if too much auditing is enabled, the security log will fill up with meaningless entries and strain agency resources. It is important to selectively choose the most appropriate layer to audit against to strike a balance between capturing meaningful data and maintaining system performance.  The agency should try to meet the Exhibit 9 auditing guidance by examining the layer closest to the FTI data.  For instance, if an application is being used to access or process FTI then it makes sense to audit user transactions related to FTI within the application as opposed to at the operating system level because the application is where the FTI is accessed from.  The operating system audit log could be reduced to capturing system level access events e.g. log-in / log-out at the operating system level.

Therefore, it is wise to audit at multiple layers so that the burden of auditing is split up among the operating system, database and application.  Collectively, the audit trail will achieve the end goal of capturing enough information to be able to see who had access to FTI and under what conditions. 

Collecting all of this audit data is only half the battle. The audit trail is ineffective if it is never monitored, analyzed, protected and retained properly. Therefore, it is the combination of having policies and procedures in place along with the collection and correlation of audit logs from all systems that receive, process, store or transmit FTI that completes the auditing picture.

To summarize, the agency must address the following areas for auditing:

  1. Audit and accountability policy and procedures must be developed, documented, disseminated, and updated 
  2. Auditable events must be identified and captured
  3. Content of audit records should be understood and defined
  4. Proper audit storage capacity must be determined and allocated
  5. Audit logs must be reviewed periodically as defined by the policy
  6. Processes must be in place to handle auditing failures
  7. Audit logs must be monitored, analyzed and reporting
  8. Time stamps must be enforced to be able to correlate events from multiple sources
  9. The audit information is sensitive and must be protected
  10. Audit information shall be retained for 6 years.

References/Related Topics

Page Last Reviewed or Updated: 29-Nov-2016