4.7.2. Security

(1) 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.

(2) 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..

(3) 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.

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

(1) 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.

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

• Removing Smart Cards before leaving work stations

• Promptly picking up ERCS prints from printers in common areas

• Updating and approving work timely and accurately

• Protecting taxpayer data from unauthorized access

• Reporting security incidences to the proper authorities timely

(3) 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:

• Ensuring users have met the prerequisites before approving BEARS requests for ERCS access

• Granting user access based on and limited to the user’s official duties and deleting permission records when no longer needed

• Training and/or providing job aids to new users regarding security requirements

• Ensuring the continued integrity of the ERCS database, which includes reviewing and correcting data issues and participating in operational reviews based on IRM requirements and local procedures

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

• Ensuring all security features are installed and operating properly on the ERCS server.

• Working OS GetServices tickets to resolve ERCS system related user issues.

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

• Ensuring all Oracle security features are installed and operating properly.

• Working OS GetServices tickets to resolve ERCS database related issues.

(1) 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.

(2) 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.

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

(1) The following are defined terms for this IRM:

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

• IRM 10.8.1, Policy and Guidance

• Security chapter of the ERCS Technical Reference Manual (TRM)

• Read Audit Trails section of the Utility Miscellaneous Programs chapter of the ERCS TRM

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

• Manual and Handbooks - this section contains the ERCS user handbooks and the ERCS TRM. The manuals describe the menu options, screens, reports and other relevant information.

• Troubleshooting - this section has information on current issues such as installing the ERCS session file and the Invalid SEID error message.

• Contacts - this section contains contact information for AIMS/ERCS Staff, Area and Campus Programs, Employee Group Codes, LB&I Contacts, and other helpful contact information.

(3) 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.

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

(2) 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.

(3) 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:

• Exam group managers in SB/SE and their administrative support staff

• Team managers in LB&I and their administrative support staff

• Territory managers (TM)s and SB/SE Area administrative support staff

• Territory managers, Directors of Field Operations (DFO)s, and LB&I Practice Area administrative support staff

• Planning and Special Programs (PSP) chiefs, section chiefs, program coordinators, technical employees and their administrative support staff

• Technical Services (TS) managers, selected technical employees and their administrative support staff

• Joint Committee Review (JCR) managers and their administrative support staff

• National Quality Review System (NQRS) managers and their administrative support staff

• Quality Review & Analysis (QRA) managers and their administrative support staff

• Centralized Case Processing (CCP) managers and selected members of their staff

• Return Preparer Office (RPO) administrative support staff

• A/E managers, analysts, assistants and their administrative support staff

• HQ ERCS analysts

Note: An employee detailed into a position above or acting for an employee in a position above, may also be granted access for the duration of the detail or acting assignment.

(4) 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:

• SB/SE and LB&I HQ analysts

• RPO analysts

• NRP analysts

• WO employees

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

(1) 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.

(2) 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.

(3) 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).

(4) 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.

(5) 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.

(6) 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.

(1) 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:

1. User’s login, this will be the employee’s SEID with lower case letters.

2. AIMS Assignee Code (AAC) or AACs - The Primary Business Code (PBC), Secondary Business Code (SBC), and Employee Group Code (EGC) combination the user needs permission for in order to run reports, update records, apply time, etc. These three codes make up the 12 digit AAC.

3. Permission type - The permission types consist of read, write, first level approval, and second level approval. With read permission users can run reports and see returns in their group. Write permission gives the user the ability to generate forms, update returns, and add or update employee records in the group. First level approval permission gives managers and acting managers the ability to approve updates made by other users in the group. In general, administrative support employees are given read and write permission, managers are given read and first level approval permission and TMs are given read and second level approval permission.

   Note: Acting managers with inventory will not routinely be given write permission during an acting assignment and must not be given permanent write permission. Users requesting temporary write permission should include the requested permission in the Special Instructions box and the reason it’s needed, when completing (or modifying) their BEARS request so it is included when the manager approves the form.

   Note: Managers may be given write permission, temporary is preferable, with TM approval. The manager must include the requested permission in the Special Instructions box and the reason write permission is needed, when completing (or modifying) their BEARS request so it is included when the TM approves the form. The BEARS request must be approved by the TM and not by proxy.

   Note: Territory managers must approve requisitions, statute updates, and transfers or closures to a return generating the command code AMSOC if made by a manager in their territory. Since an acting manager cannot approve work for returns in their own inventory, the TM may need to approve updates made to the acting manager's inventory. Therefore, if a TM approves write permissions for a manager or acting manager, they must be an active ERCS user with second level approval.

4. User Type - (Group, PSP, Review (Technical Services), Sample Review, CCP, Territory, DFO, Area, Admin, Limited). The user type determines the menu options available to the user.

5. Length of Access - The user should state if permanent access is needed. If the user only needs temporary access, they should include the start and ending dates of the assignment.

   Note: An active BEARS request gives the user access to the ERCS server. Permission records give the user access to run ERCS programs.

   Example: A user acting for the manager on an ongoing basis may need permanent access to the server, but temporary permission to approve work during each acting assignment.

   Example: A user acting for the manager for a specific period of time would only need temporary access to the server and to ERCS. They would notate start and end dates in the Special Instructions box on the BEARS request.

6. Justification - The business reason the employee needs access must be included in the Special Instructions box. If permission is needed outside the user's group or function, a justification must be input. Any other special instructions should be included such as detail assignment or acting assignment.

   Note: Except for Limited Access users, examiners access to ERCS should be restricted to acting assignments.

(1) 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.

(2) 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.

(3) 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:

• Verify a user is authorized to access ERCS.

• Determine if an employee is required to charge technical time.

• Validate the employee's AAC during inventory assignment.

• Determine if the employee should have access to the Managerial Approval menu option.

• Determine if an employee's actions require managerial approval.

• Protect an employee's tax return from unauthorized access.

• Determine who should receive employee audit security alerts.

• Determine if the employee's tax return can be audited in the area.

• Create ERCS audit trails.

• Create the SETTS file.

(4) 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.

(5) 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.

(6) 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.

(1) 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.

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

(3) 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.

(4) 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.

(5) 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.

(6) 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.

(7) 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.

(8) 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.

(9) 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.

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

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

(12) 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.

(13) 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:

(1) 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:

• A user enters their own Social Security Number (SSN) or the SSN of a spouse (if a joint return was filed)

• The source code on a return is changed to or from Source Code 46, "Employee Return"

• The "Employee Audit" indicator is turned on or off on a return

• An unauthorized user attempts to access an employee's return

• A user attempts to add an employee return to ERCS for an employee who should not be audited in the same area

• A employee's return is on AIMS and during AIMS to ERCS processing, the program attempts to add the return to ERCS in an area where the employee should not be audited

• The addition of a high profile employee return to ERCS (such as the Security Officer)

(2) 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. SeeIRM 4.7.5, Planning and Special Programs (PSP), for more information about the employee audit email.

(3) 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.

(4) 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.

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

(1) 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.

(2) ERCS captures audit trail information for the following events:

• Addition or deletion of taxpayer records

• Modification and managerial approval for selected updates to return information

• Research of taxpayer records

• Addition of employee records

• Modification of selected employee information

• Addition, deletion or modification of ERCS permissions

• User access to the ERCS Main Menu

• Selected events regarding employee returns under audit

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

• Time and date of the event

• User identification

• Approver’s identification, if the action required approval

• Type of activity (add, update, research, etc.)

• Data that was accessed or changed

• Program that was executed

(4) 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.

(1) 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.

(2) 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.

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