1.35.23 Integrated Financial System Security

Manual Transmittal

October 31, 2019

Purpose

(1) This transmits revised IRM 1.35.23, Financial Accounting, Integrated Financial System Security.

Material Changes

(1) IRM 1.35.23.1, Program Scope and Objectives, added to conform to the new internal control requirements described in IRM 1.11.2, IRM process. Also, renumbered and updated existing IRM content to place information involving internal controls for the under this subsection. All other subsequent subsections were renumbered accordingly.

(2) IRM 1.35.23.1.1, Background, updated background to include/mention new procurement module in IFS processing and Identity Management (IDM) provisioning.

(3) IRM 1.35.23.1.3, Responsibilities, update to responsibilities and addition of Deputy Associate CFO for Administrative Financial Management.

(4) IRM 1.35.23.1.3.1, Deputy Associate CFO for Administrative Financial Management, added to organization structure.

(5) IRM 1.35.23.1.3.2, Director, Financial Management Systems, updated to reflect change to name.

(6) IRM 1.35.23.1.3.3, Manager, System Security and Compliance, updated to reflect change to section name.

(7) IRM 1.35.23.1.6, Terms/Definitions, updated definitions.

(8) IRM 1.35.23.1.7, Acronyms, updated acronym definitions and descriptions.

(9) IRM 1.35.23.2.1, Integrated Financial System - Security Administration, updated to reflect current process and addition of PPS to IFS.

(10) IRM 1.35.23.2.3, End User Access, updated to reflect current process.

(11) IRM 1.35.23.2.4, Processing OL5081 Requests, updated to reflect current process.

(12) IRM 1.35.23.2.5, Firecall Procedures for the Integrated Financial System, updated to reflect current process.

(13) IRM 1.35.23.2.7, IFS Security Monitoring, updated to reflect current process.

(14) IRM 1.35.23.2.7.1, Daily Processing of OL5081 Requests, updated to reflect current process.

(15) IRM 1.35.23.2.7.2, Bi-weekly Quarantine Report, added to reflect current process.

(16) IRM 1.35.23.4 Federal Information Security Management Act, updated to reflect current IT process.

(17) IRM 1.35.23.4.1 Risk Acceptance and Risk-Based Decisions, updated to reflect current IT process.

Effect on Other Documents

IRM 1.35.23, dated June 15, 2017, is superseded.

Audience

IFS security administrators responsible for ensuring the Integrated Financial System has proper security controls in place.

Effective Date

(10-31-2019)

Mike Gomes
Deputy Associate CFO for Administrative Financial Management

Program Scope and Objectives

  1. Purpose: This IRM provides background information, objectives and standards for security and compliance activities for the Integrated Financial System (IFS). It also documents the policies and procedures used to validate the IFS internal controls, as required by the Federal Information Security Management Act (FISMA) of 2002, as revised by the Federal Information Security Modernization Act of 2014.

  2. Audience: System Security and Compliance (IFS Security) section users.

  3. Policy Owner: Deputy Associate CFO for Administrative Financial Management (FM).

  4. Program Owner: Director, Financial Management Systems.

  5. Primary Stakeholders: The primary stakeholders of this IRM are the Financial Management System employees who administer and enforce IFS security policy, procedure and compliance.

  6. Program Goals: The goal of this IRM is to provide guidance for administering established internal controls and adhering to IFS security policy and compliance.

Background

  1. IFS, comprised of the ERP Central Component (ECC), Business Warehouse (BW) and Procurement for Public Sector (PPS) runs the IRS’s core administrative financial systems, including expenditure controls, accounts payable, accounts receivable, general ledger, budget formulation and procurement. The system also includes managerial cost accounting capabilities that enable the IRS to make informed and timely performance-based business and budgetary decisions.

  2. IFS Security uses the Identity Management (IDM) program to automatically provision user roles in the IFS backend systems, ECC, BW and PPS. IDM receives data from OL5081 during an hourly upload program and provisions or removes user’s roles as requested.

  3. The Office of Management and Budget (OMB) Circular A-130, Appendix III, Security of Federal Automated Information Resources, requires federal agencies to certify and accredit their IT systems. This activity also falls within the purview of FISMA, which consolidates many security requirements and guidance into an overall framework for managing information security and protecting the nation's critical information infrastructure from harm.

  4. FISMA, enacted in 2002 and revised in 2014, requires each federal agency to develop, document and implement an agency-wide program to provide security for the information systems that support the operations and assets of the agency, including those provided or managed by another agency, contractor or other source. Federal agencies must conduct annual security reviews of all programs and systems and report the results to the OMB.

Authorities

  1. The authorities for this IRM include:

    1. Federal Information Security Management Act of 2002, as revised by The Federal Information Security Modernization Act of 2014 and other FISMA legislation

    2. FIPS PUB 200, Minimum Security Requirements for Federal Information and Information Systems

    3. Treasury Directive: 85-01, Department of the Treasury IT (IT) Security Program

Responsibilities

  1. This section provides responsibilities for:

    1. deputy associate CFO for administrative financial management

    2. director, Financial Management Systems

    3. manager, System Security and Compliance

Deputy Associate CFO for Administrative Financial Management
  1. The Deputy ACFO for Administrative Financial Management owns the system is the IFS authorizing official, and is responsible for overseeing the:

    1. Compliance with FISMA and related OMB, federal financial system and other financial requirements.

    2. IRS financial management system operations and monitoring financial systems for compliance with accounting standards and internal controls.

    3. Financial system modernization development support and system integrity.

    4. Monitoring of performance indicators for timeliness and accuracy.

Director, Financial Management Systems
  1. The Financial Management Systems (FMS) director is responsible for administering the:

    1. IFS operations and maintenance activities, including system enhancements and updates.

    2. Prioritization of IFS change requests, defect resolution requests and service requests.

    3. Resolution of technical and performance issues for the CFO administrative financial systems.

    4. Annual GAO financial statement audit related to data integrity of the CFO administrative financial systems.

    5. Special reporting requirements, audit extracts, and OMB Circular A-123, Management’s Responsibility for Enterprise Risk Management and Internal Control.

    6. Incorporation of new technologies to improve the quality and delivery of administrative financial systems.

    7. Administrative financial system security profiles and completing the annual FISMA requirements.

    8. IFS Security Assessment and Authorization and resolution of any identified issues.

    9. IFS/PPS Help Desk.

Manager, System Security and Compliance
  1. The manager, System Security and Compliance Section, is responsible for:

    1. Managing IFS security profiles.

    2. Maintaining and assigning all Knowledge, Incident/Problem, Service and Asset Management (KISAM) tickets related to IFS security and access issues.

    3. Managing the IFS FISMA compliance review.

    4. Providing requested documentation and assistance for the annual GAO financial statement audit.

    5. Providing requested documentation and assistance for any special reporting requirements, audit extracts and OMB Circular A-123 requests.

    6. Identifying and participating in critical IFS disaster recovery application activities.

    7. Conducting annual reviews of external systems that feed data into IFS.

    8. Providing system support for monthly, quarterly and annual close operations.

    9. Analyzing business processes and best practices to identify potential areas for operational improvement.

Program Management and Review

  1. Program reports: IFS Security generates the following weekly and monthly reports to assist with evaluating the performance of the IFS security controls.

    1. IFS Security Audit and Analysis System (SAAS) Report (weekly)

    2. IFS Quarantine Report (biweekly)

    3. IFS Critical Combination Report (monthly)

    4. OL5081 Reconciliation Report (monthly)

  2. Program effectiveness is measured by:

    1. Results of FISMA review

    2. IFS Security’s ability to timely develop and implement corrective actions on instances of non-compliance

    3. Results of A-123 findings of compliance

Program Controls

  1. The following controls are in place to ensure adherence to and compliance with IFS Security:

    1. Annual FISMA review in which Cybersecurity tests all security controls during a three-year cycle.

    2. IFS Security follows segregation of duties rules when assigning roles in the system, protecting IFS data by limiting access to all users based on their job function.

    3. Firecall access for developers.

Terms/Definitions

  1. The following terms and definitions apply to this program:

    1. Accountability - The traceability of actions performed on an information system to a specific system entity (user, process and device).

    2. Audit - An independent review and examination of records and activities to assess the adequacy of system controls, to ensure compliance with established policies and procedures and to recommend necessary changes in controls, policies or procedures.

    3. Audit trail - A chronological record of system activities for reconstruction, review and examination of each event in a transaction from inception to the output of final results.

    4. Firecall - A method established to provide emergency access to a secure information system in an emergency, time-critical situation. In the event of a critical error or abnormal end, unprivileged users can gain access to key systems to correct the problem.

    5. Identification - The process of verifying the identity of a user, process or device, usually as a prerequisite for granting access to resources in an information system.

    6. Live data - Production data in use (production, testing, development), which often contains sensitive but unclassified (SBU) data and may contain personally identifiable information (PII).

    7. On-going authorization (OA) - The subsequent risk determinations and risk acceptance decisions taken at agreed upon and documented frequencies in accordance with the organization’s mission/business requirements and organizational risk tolerance. An OA is a time-driven or event-driven security authorization process whereby the authorizing official (AO) is provided with the information regarding the near real-time security state of the information system (including the effectiveness of the security controls employed within and inherited by the system) to determine whether the mission/business risk of continued system operation is acceptable.

    8. Plan of Action and Milestones (POA&M) - A key document identifying specific measures that are planned to correct weaknesses or deficiencies noted in the security controls during the security control assessment; and to address known vulnerabilities in the information system. It details resources required to accomplish the elements of the plan, any milestones in meeting the tasks and scheduled completion dates for the milestones.

    9. Profile - A set of user data that administrators (and sometimes business users) can display and modify. It includes attributes such as name, e-mail address and language.

    10. Risk - A measure of the extent to which an entity is threatened by a potential circumstance or event and typically a function of the likelihood of: (1) the adverse effects if the circumstance or event occurs and (2) the likelihood of occurrence.

    11. Risk assessment - The process of identifying, prioritizing and estimating risks. This includes determining the extent to which adverse circumstances or events could affect an enterprise. Uses the results of threat and vulnerability assessments to identify risk to organizational operations and evaluates those risks in terms of likelihood of occurrence and impacts if they occur. The product of risk assessment is a list of estimated potential impacts and unmitigated vulnerabilities. Risk assessment is part of risk management and is conducted throughout the Risk Management Framework.

    12. Risk based decision (RBD) - A decision made by individuals responsible for ensuring security by utilizing a wide variety of information, analysis, assessment and processes. The type of information considered when making a risk-based decision may change based on life cycle phase and decision is made taking entire posture of the system into account. Some examples include: formal and informal risk assessments, risk analysis, assessments, recommended risk mitigation strategies, and business impact. To document risk-based determinations, IT/Cybersecurity has created a standard operating procedure (SOP) and associated Form 14201, Risk Acceptance Request.

    13. Role - A collection of transaction codes and authorization objects used in various business scenarios. Roles are assigned to system users, resulting in authorization profiles that allow them to access and process transactions in the system.

    14. Segregation of duties - A key internal control concept under which no single individual has complete control over a financial transaction from beginning to end.

    15. System administrator - An individual employed to maintain and operate the technical aspects of an information system, including system roles. Usually charged with supporting and maintaining computer systems, and planning for and responding to service outages and other problems.

    16. User account - An operating system data object containing information identifying a user to an operating system. A user account typically contains a user’s name and password, group memberships and rights and permissions for accessing an information system and its resources.

Acronyms

  1. The following acronyms apply to this program :

    ACRONYM DESCRIPTION
    AO Authorizing Official
    ASCA Annual Security Control Assessment
    ATO Authorization to Operate
    BW Business Warehouse
    DAA Designating Approving Authority
    DR Defect Report
    ECC ERP Central Component
    eCM Enterprise Continuous Monitoring
    ELC Enterprise Life Cycle
    ERB Engineering Review Board
    ERP Enterprise Resource Planning
    FIPS Federal Information Processing Standards
    FISMA Federal Information Security Management Act
    FM Financial Management
    FMS Financial Management Systems
    GAO Government Accountability Office
    IDM Identity Management
    IFS Integrated Financial System
    ISCM Information Security Continuous Monitoring
    ISCP Information System Contingency Plan
    IT Information Technology
    KISAM Knowledge Incident Service and Asset Management
    NIST National Institute of Standards and Technology
    OL5081 On Line 5081
    OMB Office of Management and Budget
    PGLD Privacy, Governmental Liaison and Disclosure
    PCLIA Privacy and Civil Liberties Impact Assessment
    PII Personally Identifiable Information
    POA&M Plan of Action and Milestones (POA&M)
    POC Point of Contact
    PPS Procurement for Public Sector
    RBD Risk-Based Decision
    SAAS Security Audit and Analysis System
    SAR Security Assessment Report
    SBU Sensitive but Unclassified
    SME Subject Matter Expert
    SNC Secure Network Communications
    SOP Standard Operating Procedure
    SP Special Publication
    SSP System Security Plan
    TFIMS Treasury FISMA Inventory Management System

Related Resources

  1. Related resources for this IRM include:

    1. IRM 1.4.3, IRS Guidance for Implementing OMB Circular A-123.

    2. IRM 10.8.1, Policy and Guidance.

    3. IRM 10.8.8, Sensitive But Unclassified (SBU) Data Policy: Protecting SBU in Non-Production Environments.

    4. NIST Special Publication (SP) 800-53 Revision 4, Security and Privacy Controls for Federal Information Systems and Organization.

    5. OMB Circular A-123, Management's Responsibility for Internal Control.

    6. OMB Circular A-130, Appendix III, Security of Federal Automated Information Resources.

Integrated Financial System Security Administrators

  1. The IFS system security administrators are CFO employees assigned to the FMS Office, System Security and Compliance Section (IFS Security).

  2. IFS Security has two main functions:

    1. Manage all IFS security administration activities.

    2. Manage all activities needed to meet annual requirements of FISMA.

Integrated Financial System - Security Administration

  1. IFS, comprised of the ERP Central Component (ECC), Business Warehouse (BW) and Procurement for Public Sector (PPS), runs the IRS core administrative financial systems, including expenditure controls, accounts payable, accounts receivable, general ledger, procurement and budget formulation. IFS Security manages all IFS system administration activities, including:

    1. Establishing user accounts and profiles, approving and denying user access and assigning IFS roles.

    2. Monitoring IFS user access.

    3. Establishing an enforcing IFS Security policies and procedures.

  2. IFS users will submit an OL5081 to request and obtain IFS access.

  3. IFS Security uses the Identity Management (IDM) program to automatically provision user roles in the IFS backend systems, ECC, BW and PPS. IDM receives data from the OL5081 system during an hourly upload program and provisions or removes user’s roles as requested.

Provisioning Access to IFS

  1. When provisioning access, IFS Security will perform the following steps:

    1. IFS Security utilizes the OL5081 system to process requests for system access. Users are required to obtain access to IFS through the OL5081.

    2. Each business unit has a security coordinator approval group that must approve OL5081 role requests for their business unit before IFS Security provisions the role. Certain roles that provide enhanced access have restrictions that require additional approval levels after the business unit security coordinator approves the request.

    3. IFS Security reviews the role requests and determines whether to approve. They will consult the user, the user’s manager or the role owner as required.

  2. The approval chain for approving an OL5081 request is as follows:

    1. First-line manager

    2. Business unit security coordinator

    3. Restricted role approval (where applicable)

    4. IFS Security administrator

  3. IFS developers do not have access to the IFS Production environment apart from temporary access, which is granted under the IFS Firecall process.

Role Provisioning

  1. IFS Security processes OL5081 requests related to IFS roles.

  2. Once the user’s manager and the approval groups have approved the OL5081, the request is forwarded to IFS Security’s first approval group - NO.CFO.IFS.5081.FS.APPROVERS.

    1. For add requests, IFS Security verifies the user is eligible for the role and then completes the first approval.

    2. If IFS Security denies the role request, the OL5081 system will automatically notify the user of the denial.

  3. Once approved, the request moves to the IDM APPROVAL group. IDM retrieves the information from OL5081 and posts it to IFS.

  4. After IDM uploads the role information and provisions the role, IFS Security will approve the role in OL5081 a second time to complete the process.

Firecall Procedures for the Integrated Financial System

  1. Firecall procedures, which are system-specific, shall be implemented for use only in emergency situations when elevated access is required. See IRM 10.8.1.4.1.1.6, Firecall Account and the Firecall Access Standard Operating Procedure for more information.

  2. Contractors with developer access and IT developers (IFS/IT contractors) do not have access to the IFS production environment unless approved through the firecall process. Firecall access should only be granted for a limited period and IFS role assignment should be based on the security principle of least privilege. These firecall procedures provide IFS production access to IFS developers and functional teams when needed to support development and work defect tickets.

  3. IFS/IT contractors will use IFS Security’s firecall form to document the request. The request must include the reason for the roles and the expected time-frame the roles are needed.

  4. The IFS/IT contractors will obtain approval from CFO management and contractor management for firecall access.

  5. Upon firecall approval, IFS Security will assign the requested roles for the requested duration of time.

  6. IFS Security will sign the firecall approval form after granting access and will return the signed firecall form to the IFS/IT contractor coordinating the firecall request.

  7. If the firecall task cannot be completed within the approved time-frame, a firecall extension request can be made and granted.

  8. The extension request for firecall access must be approved by IFS/IT contractor management.

Role Maintenance

  1. Role maintenance is periodically performed in IFS to manage user roles and profiles, and to update authorization data based on selected menu functions.

  2. IFS user roles are primarily based on business unit and job-title. Roles are the connection between the user and corresponding authorizations that permit users to successfully process IFS transactions in the system.

  3. Formal change-management procedures are required when roles are changed to add or remove transactions and field values or when new roles are created in IFS to reflect business changes.

  4. The following criteria will be used when determining if/when changes to an IFS role should be presented to the Engineering Review Board (ERB) for review and approval:

    1. Current transaction authority is removed from a role (not duplications).

    2. Role changes impacting 100 or more users.

    3. Privacy Act information added to a role.

  5. The following criteria will be used by the role owner and developers, when presenting authorization and role maintenance activities to the ERB:

    1. Review requested role changes and activities with the SME.

    2. Open a defect ticket in ClearQuest.

    3. Develop the role change in the test environment system.

    4. Test the role change for completeness.

    5. Prepare the ERB form to document the change being requested and include all supporting attachments and documentation.

    6. Upload the approved ERB form and attach it to the associated defect ticket in ClearQuest.

    7. After ERB approval, the role change moves through ClearQuest along the systems development life-cycle to production.

  6. Documentation for role maintenance activities is maintained in ClearQuest and through the recordation of meeting minutes at each scheduled ERB.

IFS Security Monitoring

  1. IFS Security performs checks on a daily, weekly, bi-weekly, monthly and semi-annual basis that include:

    1. Daily processing of OL5081 requests to add/remove user access.

    2. Biweekly review to quarantine and lock inactive user accounts.

    3. Monthly review of critical IFS role combinations to mitigate separation of duty risks.

    4. Semi-annual recertification IFS Security to mitigate separation of duty risks.

    5. Weekly review and analysis of IFS Security Audit Analysis System (SAAS) Log data from IT/Cybersecurity.

    6. Monthly reconciliation of OL5081 user roles to the assigned roles in IFS.

Daily Processing of OL5081 Requests
  1. IFS Security maintains the roles so users have the correct and most appropriate access to perform their assigned duties.

  2. IFS Security reviews and processes OL5081 requests for access daily.

  3. All users that need to be added to or deleted from IFS must submit their request in OL5081.

  4. Once the user’s manager approves the OL5081, the system routes the request through an established approval chain process, which is usually based on business unit. The approval chain process for IFS role requests is generally as follows:

    1. Employee request

    2. Employee management approval

    3. Business unit/IFS security coordinator approval

    4. IFS Security approval

  5. Additional approvals may be required and incorporated into the approval chain for roles that provide access to PII data.

  6. IFS Security uses various checks to verify roles and their appropriateness for the user. Prior to approving an OL5081 and granting access, further investigation on the part of IFS Security may be warranted to determine the appropriateness of the role for the user, including:

    1. Business unit check – prior to approving an OL5081, IFS Security verifies that the requested role is for the correct business unit. As a rule OL5081s should only be approved when the OL5081 matches the business unit of the user. The user’s business unit can be verified by checking the Discovery Directory or by checking the address book on Outlook.

    2. Job assignment check – this check involves checking the OL5081 role request against the user’s job assignment.

    3. Segregation of duties check – before granting access to a role, IFS Security reviews the user’s existing roles to determine if any changes will cause segregation of duties. Any role requests causing this issue will be denied. Examples of role assignments that create a segregation of duties issue include the following:
      • Accounts Payable and Accounts Receivable roles
      • Accounts Payable and Approver roles

  7. IFS IT contractors should not be given access to the IFS production environment; however, temporary access may be authorized under the firecall process.

  8. IFS Security is the last group to approve or deny OL5081 requests.

  9. All users will complete an annual recertification in the OL5081 system. See OL5081 Employee Guide for more information.

Bi-weekly Quarantine Report
  1. IFS Security runs the bi-weekly quarantine report to verify inactive IFS users do not have access to the system.

  2. IFS user accounts are disabled (locked) after 120 days of inactivity and quarantined (deactivated) after 240 days of inactivity. IFS Security runs the report every other Tuesday.

  3. User must submit a KISAM ticket to unlock their account. Once unlocked, the user has two (2) weeks to log into their account or they will be locked again due to inactivity.

  4. If an account has been quarantined, the user will need to submit new OL5081 requests for any roles they require to reactivate the account.

Monthly Critical Combinations Report
  1. IFS Security runs the monthly Critical Combinations Report to confirm separation of duty and that the principle of least privilege is in place for most IFS users.

  2. The Critical Combination Report provides a current snapshot of user roles, transactions, and permissions in the system. IFS Security runs the report against a standard set of combined critical transaction scenarios to highlight and capture all user profiles with multiple or stacked roles that match the critical combination scenarios.

Semi-annual Recertification of Security Roles
  1. IFS security roles must be recertified in the OL5081 system every six months to certify the integrity of key IFS security profile transactions.

Security Audit and Analysis System Log Reviews
  1. The IFS accounting system records security audit log information. Each week IT/Cybersecurity extracts the data for the Security Audit Analysis System (SAAS) interface, which generates multiple reports in an Excel format.

  2. IT/Cybersecurity emails the Excel reports to IFS Security for review and analysis. The reports include:

    1. Failed logons – users with unsuccessful login attempts.

    2. Critical transaction codes – critical transactions executed by the user in the system.

    3. Unusual logon times – system logons outside of normal business hours.

  3. If IFS Security does not receive the reports timely, they will notify IT/Cybersecurity and request the status.

  4. IFS Security escalates late report submissions to the Manager, System Security and Compliance section.

OL5081 Reconciliation
  1. IFS Security performs a monthly OL5081 reconciliation process to synchronize IFS user access with current OL5081 authorizations to verify the requested OL5081 actions occur in IFS.

Federal Information Security Management Act

  1. FISMA requires federal agencies to develop, document and implement an agency-wide program to provide security over the systems and data that support the operations and assets of the agency. Federal agencies must conduct annual security reviews of all programs and systems, reporting the results to OMB. IFS is subject to FISMA requirements.

  2. IT/Cybersecurity develops and maintains IRS’s enterprise IT security policies to protect the IRS against potential IT threats and vulnerabilities, and to certify compliance with federal mandates and legislation. The following IRM sections provide the minimum baseline security policies and requirements for all IRS systems:

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

    2. IRM 10.8.60, Information Technology (IT) Security, IT Service Continuity Management (ITSCM) Policy and Guidance provides policies and guidance to carry out IT Service Continuity Management for information systems security and availability regarding Information System Contingency Plans (ISCP) and Disaster Recovery (DR)

    3. IRM 10.8.62, Information Technology (IT) Security, Information System Contingency Plan (ISCP) and Disaster Recovery (DR) Test, Training and Exercise (IT&E) Program defines test, training and exercise processes to make sure the IRS can recover and restore its systems in the event of a disruption, disaster or catastrophe.

    4. IRM 10.5.2, establishes the privacy framework for privacy compliance and assurance programs and activities, including privacy risk assessments such as Privacy and Civil Liberties Impact Assessments (PCLIAs) and Servicewide risk assessments, as well as various privacy reporting requirements.

Plan of Action and Milestones (POA&M)

  1. A POA&M is used to address and track the correction of vulnerabilities in an information system. It lists the key milestones required to correct the vulnerability, calculates the resources required to accomplish each one and tracks the completion dates of the individual milestones as well as the overall completion date.

  2. For additional information on POA&M requirements, see IRM 10.8.1.4, Security Controls, Enhancements, and Supplemental Guidance.

Risk Acceptance and Risk-Based Decisions

  1. Any exception to this policy requires that the Authorizing Official (AO) make a Risk-Based Decision (RBD).

  2. Risk-Based Decision requests shall be submitted in accordance with IRM 10.8.1 using Form 14201, Risk Acceptance Request.

  3. See IRM 10.8.1 for additional guidance about risk and acceptance.