All ERCS users, their managers, and ERCS support personnel (including system administrators, database administrators and ERCS developers) should be familiar with this IRM to ensure they are aware of the system security features and the requirements for ERCS access.

Users must be aware of the potential for Unauthorized Access of Taxpayer Accounts (UNAX) violations from the use of ERCS. Data from ERCS should be accessed only for IRS business purposes. Users should promptly retrieve ERCS reports from printers or fax machines in order to prevent unintentional disclosure. Audit trails are created and subject to review for all user accesses of taxpayer data. For more information about UNAX, see IRM 10.5.5, IRS Unauthorized Access, Attempted Access or Inspection of Taxpayer Records (UNAX) Program Policy, Guidance, and Requirements..

Per IRS security requirements, IT employees are not permitted to have access to taxpayer data. No IT employee should be approved for ERCS access and any user transferred or detailed to an IT position must submit a Remove Access request to have all permission records removed.

IRM 10.8.1, Policy and Guidance, establishes the security program and the policy framework for the IRS.

Ensuring the security of ERCS is the responsibility of every user and support personnel including the AIMS/ERCS staff, the ERCS system and database administrators, and the ERCS developers.

ERCS User Responsibilities: All users are responsible for ensuring the security of the ERCS system. This includes but is not limited to the following:

AIMS/ERCS (A/E) Staff Responsibilities: In addition to user responsibilities, the A/E staff security responsibilities include but are not limited to the following:

System Administrator (SA) Responsibilities: The ERCS system administrator responsibilities include but are not limited to:

Database Administrator (DBA) Responsibilities: The database administrator responsibilities include but are not limited to:

ERCS creates audit trails for selected changes to returns, employee records, and permission records. A special audit trail is also created when users enter a taxpayer identification number (TIN) or a taxpayer name on ERCS.

There are security checks within ERCS to ensure unauthorized users do not access programs and authorized users are kept within the boundaries of their permissions. These checks are performed automatically and silently each time a user attempts to access ERCS. The user has no ability to prevent the checks.

See Exhibit 4.7.2-1, Acronyms and Definitions, for acronyms used in the IRM.

The following are defined terms for this IRM:

The following resource documents contain information regarding IRS security requirements and ERCS programs related to creating and reading ERCS audit trails:

The ERCS book in the Virtual Library contains helpful information to resolve problems and answer questions. The following types of information is available:

For security issues concerning record of tax enforcement results (ROTER) information, see the Section 1204 Website. IRM 1.5, Managing Statistics in a Balanced Measurement System, provides further guidelines for the appropriate use of statistics by managers and employees.

Employees must have reported to the group before access to ERCS is requested.

Employees must have completed a UNAX Briefing and UNAX Certification prior to being given access to ERCS data. The employee's manager is responsible for ensuring this has been completed prior to approving the BEARS Add Access request.

Employees hired into a position requiring ERCS access are granted access on the approval of their managers and the A/E staff. These positions include:

An employee may be granted access on the approval of their manager and an HQ ERCS analyst if there is justification that access is needed in order to perform the user's official duties. These employees include the following:

Shared administrative associates from TE/GE and SB/SE Collections supporting SB/SE and LB&I groups are required to meet the same prerequisites.

To obtain access to ERCS, employees must complete a BEARS request. Employees may need to submit more than one request for ERCS access if permission is needed in more than one area or in both LB&I and SB/SE. If the employee requires more than one BEARS request for ERCS, the first application requested must be within the user's support area and Business Operating Division (BOD). The user should wait until they have accessed ERCS for the first time before submitting additional requests to other areas. There is an exception for HQ analysts, NRP analysts, and WO employees. Refer to IRM 4.7.2.2.2 (5) for BEARS procedures for these employees.

ERCS users are supported by the A/E staff located in the user's local area or CCP campus, with the exception of employees in Fraud/Bank Secrecy Act (BSA),Withholding Exchange and International Individual Compliance (WEIIC), and WO employees. Fraud/BSA, WEIIC, and RPO users have their own A/E support staff. WO employees are supported by Area 206, Western. Refer to the AIMS-ERCS Staff Listings for support contact information.

It is important to select the correct BEARS ERCS application because each one is routed to the local A/E staff for approval, creation of the user's ERCS employee record, work schedule profile and inputting permission records. The ERCS BEARS Application tables, Exhibit 4.7.2-2 through Exhibit 4.7.2-6, include all ERCS applications for requesting access. Except for HQ analysts, NRP analysts, and WO employees, the exhibit tables should be used to determine a user's initial BEARS application selection. For the excepted employees refer to IRM 4.7.2.2.2 (5).

On rare occasions if access is needed to update records for an additional area or BOD, subsequent BEARS requests must be completed. Write permission across areas requires justification in the Special Instructions box on the request.

HQ analysts, NRP analysts, and WO employees must have an approved BEARS request for PROD ANALYST ERCS HQ ANALYST prior to requesting any other ERCS BEARS application. This ERCS application is routed to the HQ ERCS analysts for approval. An HQ ERCS analyst will contact the employee or employee’s manager to determine what level of access and permission records are needed, and then will inform the employee which subsequent BEARS ERCS application to submit. The HQ ERCS analyst will alert the A/E managers in the areas impacted to let them know that ERCS access has been granted.

Information for BEARS applications for Statistical Sampling Inventory Validation Listing (SSIVL), Tableau and A/E staff are discussed in IRM 4.7.10, AIMS/ERCS Staff. See Headquarters Contacts for AIMS, ERCS, SETTS, SSIVL, and Tableau for contact information for the HQ analysts who support these programs.

BEARS requests for new users must contain sufficient information for the A/E analyst to add the employee's permission records on ERCS as this document serves as the official record of the user's approved level of access. The following information must be included in the Special Instructions box, either by the employee, the employee's manager, or the A/E analyst:

ERCS interfaces with the Corporate Authoritative Directory Service (CADS) to download employee information, including the employee’s SEID, into the ERCS database. Only data for SB/SE, LB&I, WO, and RPO employees is downloaded. When an employee record is added to ERCS, the user enters the employee's SEID. It is validated against the downloaded employee data from CADS (Discovery Directory). If a user is unable to add a new employee to ERCS because the employee's SEID is invalid, the user should refer to the instructions on the Invalid SEID Error Message page under Troubleshooting in the ERCS book to resolve the issue.

Employee records are added by a user with write permission for the AAC the employee will be assigned to. This includes administrative support staff or the local A/E staff.

The information on the ERCS employee record should be entered accurately and completely. Any changes to the record should be updated as soon as they are known. ERCS employee record data is used to:

Employee records should be updated when an employee’s name changes. If an employee has been issued a pseudonym for security reasons, the pseudonym should be entered on the ERCS employee record followed by a space and the literal XX. This will alert the A/E staff that the name on the employee record is not the employee’s real name.

ERCS employee records should be inactivated when the employee leaves the IRS or transfers within the IRS to a non-ERCS position. If the employee’s time is entered on ERCS, the end date on the employee record must be set to the last day the employee is required to enter time. Otherwise, the last day the employee worked should be entered for the employee’s end date. The login name should not be removed from the ERCS employee record when an employee record is inactivated. It is a link to the ERCS audit trails.

A user’s login must be entered in the Login field of the employee record or the user will not be able to access ERCS.

Permission records determine what menu options are available to a user within the ERCS Main Menu. They also give users the ability to run reports, update employee records and returns, input time, and approve work.

Permission records are to be added when a BEARS request is processed or the user will not be able to access ERCS.

The permission types are read, write, first level approval, and second level approval. Managerial approval can be restricted so the user can only approve updates by return. Permission records are based on AACs. For example, a group manager may be given read and first level approval permission for the group's AAC. A CCP user in Memphis may be given read and write permission for returns in Memphis CCP.

ERCS programs use the employee's permission records with the ERCS national status code files to restrict access based on the status code on the return. For example, a group user may only update returns in a group status. CCP users may only update returns in a CCP status. See Document 6036, Examination Division Reporting System Codes Booklet, for a list of status codes used by examination.

Permission records are added by the A/E staff. Managers with permanent first level approval permission can delegate temporary first level approval permission for their group to an acting manager as long as the employee has an active ERCS login. Approval permission should only be granted for the length of the acting assignment. Managers with permanent write permission may delegate temporary write permission for their group to a shared administrative support employee in another group if assistance is needed.

For permanent permission changes within the same area and temporary changes lasting over 30 days, the user is required to submit a Modify Access request via BEARS.

Permission can be permanent or temporary. Temporary permission is granted for up to 180 days, if needed for a longer period of time, permanent permission should be granted. The user will request removal of the permission records via a Remove Access BEARS request when no longer needed.

A temporary, emergency permission change within the same area may be granted by the user's local A/E analyst. The request should be made by management via e-mail. For emergency permission not covered in these instructions, contact an HQ ERCS analyst.

If an employee acts for their manager, first level approval permission will be granted with a beginning date and an ending date covering the acting assignment. If the acting assignment ends early, and permission was delegated by the group manager, the manager will update the permission records to the correct end date, but the ERCS employee record will remain active.

When an employee record is inactivated, the ERCS program updates the employee's permission records to end on the employee's inactivation date.

If a user no longer needs ERCS access due to a change in position or duties, a Remove Access BEARS request must be input.

If a user is suspended from active duty the manager must input a Remove Access BEARS request for the user’s ERCS access if one isn’t systemically generated.

Access to Menu Options 11 through 19 on the ERCS Login Menu are granted via special BEARS applications. These BEARS requests go through the HQ ERCS analysts or the HQ SSIVL analysts for approval and to add the special permissions enabling the user to access the menu options. These options are described below:

An employee audit occurs when the tax return of an IRS employee is examined. ERCS provides special security features for employee returns under audit. When any of the following events occur an audit trail is created and an ERCS system email alert is generated:

If there is a Security Officer with ERCS access for the area, the employee audit e-mail is sent to the Security Officer. Otherwise, the ERCS system email is sent to the PSP TM. See IRM 4.7.5, Planning and Special Programs (PSP), for more information about the employee audit email.

Not all employee audit alerts are an indication the user is doing something inappropriate. For example, alerts may be generated when a user accesses an employee's return by taxpayer identification number (TIN), and the program finds one tax period assigned to the user's group and one tax period controlled in another group or function. An alert will be generated for the tax period that is not in the user's group. Some alerts are an indication of inappropriate access, for example, when a user enters their own SSN. See Employee Audits under Codes and Procedures in the ERCS book for more information.

Employee returns are not included on ERCS reports and screens if the user is not authorized to see the data. In general, this means the user must have permission to the AAC of a return before the return information may be viewed, regardless of the status code. Users are not notified when an employee audit alert is generated for their access.

For more information about employee audit security features refer to the Security chapter of the ERCS TRM.

An ERCS audit trail is a record of an event initiated by a user or program on the ERCS server. The event can be anything from execution of a program to accessing or changing data. Audit trails can be used to research when changes were made to data, and to determine who input or approved the changes. Audit trails can also detect potential unauthorized access or suspicious activities.

ERCS captures audit trail information for the following events:

The event information captured in an ERCS audit trail includes, but is not limited to the following:

Audit trail information may be accessed from special ERCS menus by A/E analysts, HQ ERCS analysts, and designated system security officers. Managers should consult their local A/E staff for assistance if information from an ERCS audit trail is needed. For more information about ERCS audit trails refer to the "Read Audit Trails" section of the Utility Miscellaneous Programs chapter of the ERCS TRM. For information about the responsibilities of the A/E staff regarding the ERCS audit trails, see IRM 4.7.10, AIMS/ERCS Staff.

All modernized IRS systems containing taxpayer data, like ERCS, are required to send their system and program audit trails to the Security Audit and Analysis System (SAAS). Audit trail repositories like SAAS aid the IRS and TIGTA in detecting potential unauthorized accesses to IRS systems and data.

Security specialists from Cybersecurity are responsible for performing the review of audit trails sent to SAAS. Reports from SAAS are also sent to the HQ ERCS analysts for review and verification that accesses are business related.

Refer to IRM 10.8.2, IT Security Roles and Responsibilities, for more information including actions to take for suspected security incidents.