2.21.1 Introduction to Requisition Processing for Information Technology (IT)

Manual Transmittal

April 11, 2017

Purpose

(1) This transmits revised IRM 2.21.1, Requisition Processing for IT Acquisition Products and Services, Introduction to Requisition Processing for Information Technology (IT) .

Material Changes

(1) Editorial changes have been made throughout i.e. names, references, and uniform resource locators were updated throughout the section

(2) Revisions were made to address internal control requirements.

(3) Removed reference regarding signature authorities for IT supplies and administrative overhead (Scope).

(4) Updated Signature Authority for requisitions up to $50,000 that support non-IT goods and administrative services (Scope)

(5) Removed multiple Point of Contacts Exhibit

(6) Updated approval process for IT requisitions initiated by the Business Units and functional offices. (Requisition Signatory Authority Approval)

(7) Added new requirement for Service Contracts (Contractor Coding Worksheet) only from the OFPP.

(8) Added information on the new Integrated Procurement System (IPS).

(9) Removed reference regarding (webRTS)

(10) Removed reference to IRS MITS, and replaced with IT and link

(11) Updated to reflect change to (Signature) Silvana G Garza, Chief Information Officer

(12) Updated to change reference from CTO to CIO (Delegation Signature Authority)

(13) Updated language to reflect change in Contact Person (Point of Contact)

(14) Updated reference regarding Work Request

(15) Removed reference section regarding End User Equipment and Services (ASSETMGT)

(16) Updated reference to IT Security Checklist, and link in new updated IT Security Checklist

(17) Updated Financial Plan Management (FPM) in Glossary

Effect on Other Documents

IRM 2.21.1, dated February 26, 2013, is superseded.

Audience

All IRS personnel involved in the processing of requisitions for IT products and services.

Effective Date

(04-11-2017)


S. Gina Garza
Chief Information Officer

Introduction

  1. Purpose: The purpose of this document is to provide guidance:

    • in completing IT requisitions for products/services; and

    • to all IRS personnel on the critical elements necessary to complete the requisition approval process.

  2. Audience: The audience or otherwise primary users of this IRM are all IRS personnel involved in the processing of requisitions for IT products and services.

  3. Policy Owner: Angelika S. Sweitzer, Director, Strategic Supplier Management owns the policies contained herein.

  4. Program Owner: The Strategic Supplier Management Organization is responsible for the administration, procedures, and updates related to the program.

  5. Primary Stakeholders: The primary stakeholders affected by this IRM are all IRS personnel involved in the processing of requisitions for IT products and services.

  6. Program Goals: The goal for the program associated with this IRM is to provide information and updated guidance to the end users for Requisition Processing for Information Technology (Acquisition Products and Services), as well as Delegation/Signature Authority.

  7. The requisition process described herein is included as part of a total acquisition life cycle.

  8. Web links for each major requisition review section (Disclosure, Section 508, Security, etc.) mentioned in this IRM have been included so that a Requestor (also defined as the Point of Contact) will have the capability to review the process and fill out the forms required as part of the requisition process. Most web sites will require scrolling the document for needed information.

  9. The web links included in this document are subject to change. Since revisions to IRMs are limited, it is recommended that a Requestor check the appropriate web site for the latest information. Refer to the web link below for all procurement current web links and the Procurement 101 reference Guide:

    https://portal.ds.irsnet.gov/sites/DCOSProcurement/p101/requisition/SitePages/Home.aspx

Background

  1. Delegation of Authority Modernization and Information Technology Service (MITS 2-1-1) provides IRS Information Technology executives with delegated signature authority for approving Information Technology purchases of goods and services. The CIO has responsibility for all purchases of products and services acquired by the Internal Revenue Service (IRS). http://ss.ds.irsnet.gov/sites/VCM/req_aid/req_flow_cyber.aspx

  2. IRS Information Technology is the organization responsible for approving IT requisitions and, therefore, IRS Information Technology Executives are accountable for ensuring their accuracy. IRS personnel involved in the processing of IT requisitions must follow the guidance contained in this manual.

Authority

  1. The signature authorities and associated re-delegations supported by (MITS 2-1-1) apply to requisitions for purchases of IT products and services.

  2. Signature authority up to $50,000 for requisitions that support non-IT goods and administrative services (e.g., court reporter, movers, executive certificate framing, fax/printer toner, general office supplies) and IT operating costs specifically associated with recurring billing (e.g., local/long distance phone services) must be approved by the IRS Information Technology front-line managers or higher. This authority cannot be re-delegated and acting managers are not approved as proxies. If the front-line manager is unavailable for signature, a superior manager signature must be obtained. IPS record must include signature authority. Signature authority for requisitions greater than $50,000 (cumulative) revert to standard IT requisition signature authority. http://mits.web.irs.gov/publicationsmgmt/directives/directivesdelegationorders.htm

  3. While most requisitions are for specific IT products/services, many requisitions are for block funding for IT resources to be applied to a Purchase Card. The processes outlined in this IRM also apply to this type of requisition. Users of Purchase Cards are reminded to review the IRS Purchase Card Guide (Document 9185) link and the Restricted Purchase List link for instructions on how to use the card and buying restrictions. Be sure to note the restricted Purchase Card use regarding disclosures of taxpayer returns or return information. This restriction also applies to employee/personnel and Official Use Only (OUO) information. The following web links apply: http://erc.web.irs.gov and https://portal.ds.irsnet.gov/sites/DCOSProcurement/p101/requisition/SitePages/Home.aspx, respectively.

  4. Below are web links for Credit Card Services and the Treasury Commercial Vehicles (TCV) Purchase Card Program. http://awss.web.irs.gov/ess/CCS/ccs.htm and http://erc.web.irs.gov/Displayanswers/folderContent.asp?folderID=10, respectively.

  5. This document is authorized by:

    • The Clinger-Cohen Act of 1996, also known as the Information Technology Management Reform Act (ITMRA)

    • IRM 1.1.12, Chief Information Officer

    • IRM 1.1.17.9.3, Office of Information Technology

    • IRS Policy Statement P-1-229 (new number will be P-2-4)

    • IRS Delegation Order No. MITS 2-1-1

Terms/Definitions

  1. Exhibit 2.21.1-1 (Terms/Definitions) defines the terms used in this manual.

Business Requirements

  1. All organizations within IRS are responsible for including Business Requirements as part of the requisition for IT products and services.

Business Requirements Identification

  1. All organizations within IRS are responsible for generating business requirements and ensuring the business requirements are part of their Strategic and Program Plan. When an organization identifies an IT business requirement, contact must be made with the Business Systems Planner (BSP) to ensure that the requirement is addressed in the Strategic and Program Plan.

Business Justification

  1. A Business Justification typically consists of: 1) technical requirements of the acquisition, 2) how it supports the organization’s business requirement, 3) how the business requirement supports the Strategic and Program Plan, 4) a basis of cost estimate, and 5) any other relevant information. The Business Justification does not need to follow a particular format, as long as it includes the minimum items (1-4) above, and is incorporated in the Attachment Tab under the Comments Field.

    Example:

    This technical requirement was initiated by [Name, Organization]. This requisition is for acquisition of contractors to incorporate legislative changes into project XXXXXXXX for filing season implementation. The contractor support will include requirements analysis, documentation, coding, unit and integration testing, implementation support and post-implementation support. If this requirement is not funded, project XXXXXXXX’s readiness for filing season implementation will be seriously jeopardized.

Refine Requirements

  1. For all service contract requisitions only and modifications awarded on or before March 1, 2012, must be accompanied by a signed Coding of Service Contract Requirements Worksheet including any required supporting analysis. APU No 2012-01R2, Performance of Inherently Governmental and Critical Functions and Coding of Service Contract Requirements from the Office of the Procurement Executive, effective as of May 1, 2012, redefines and provides clarification as to which service contract actions are to be coded. The coding of service contracts is now limited to:

    • Each new contract award for services obligating $25,000* or more awarded on or after March 1, 2012. Award actions include (but are not limited to) contracts, task orders, delivery orders, and BPAs.

    • All modifications to an award action meeting the criteria listed above (obligating $25,000* or more and awarded on or after March 1, 2012) must be coded.

    • Modifications awarded on or after March 1, 2012 to contracts, task orders, delivery orders, and purchase orders prior to March 1, 2012 DO NOT require coding.

    (*The $25,000 dollar value is tied to the action level set in the Service Contract Inventory Memorandum from OMB dated November 5, 2010.)

    As a reminder, Contracting Officers must still enter into the FPDS "description of requirement" field the coding determination listed on the Service Contract Coding Worksheet received from the customer. The correct FPDS Codes per the APU are: Closely Associated, Critical Functions, and Other Functions.

    The Coding Worksheet must be signed by an individual within the program office who is familiar with and responsible for the requirement. Electronic or physical signatures are acceptable. Signed Coding Worksheets and attachments must be converted to electronic format. No award can be made until this documentation is received by the CO with a customer signature(s).

    By signing the Coding Worksheet, the procurement customer certifies that the contract does not involve any inherently governmental work and that the coding determination (i.e., closely associated to inherently governmental, critical function, or other) is appropriate for the work to be completed. If obligating $150,000 or more, the customer must attach a written supporting analysis addressing how the decision was arrived at and how the customer will maintain sufficient internal capability to oversee and manage contractor activities and maintain control of its mission and operations. A sample Coding Supporting Analysis Document format is available to assist in preparing documentation. The Coding Supporting Analysis Document must address the following points:

    • Determination of the nature of the contract (or code) - which includes information from the statement of work to support this finding;

    • Determination of the contractor degree of discretion (low, medium or high risk of the contractor performing inherently governmental work); and

    • Determination that there is a sufficient level of control of operations within the program.

    The policy was mandated as part of a broad effort to assist agencies in understanding, planning, and managing their multi-sector workforce by ensuring proper controls are in place to secure a balanced workforce. See link below for further details and example of the Coding Worksheet. http://sai.ds.irsnet.gov/sites/sai/p101-gap/p101/planning/p101plan-servscntrs.aspx

  2. All requirements must be refined so the Office of Procurement is able to procure the appropriate products and/or services.

  3. A Contractor Housing Justification form (13530) is required when Contractors are to be housed in government space. The form will require a description of the contract and a complete justification in addition to the cost impact analysis to house the contractors. The completed form will need to be sent to REFM for review and approval. The signed form is required as an attached to the Requisition package to be forwarded to Procurement. See link below to obtain the form:http://core.publish.no.irs.gov/forms/internal/pdf/f13530--2008-09-00.pdf

Point of Contact

  1. Each requisition should have a primary point of contact (POC). In some cases, the Contact person may be the same individual initiating the requisition (the requestor), however, the POCs are responsible for providing Agency expertise, and resources to ensure that the IT acquisition is completed and forwarded to the Office of Procurement.

Point of Contact Responsibilities

  1. The responsibilities of the POC include the following and are also reflected in Diagram 1 - Parallel Process: Refine Technical Requirements.

    Point of Contact Responsibilities
    1. Work with the applicable IRS organization to transform the business requirement into a technical requirement.
    2. Enter a record into webIPS. For information on using webIPS, see the webIPS Overview at:
    Integrated Procurement System
    3. Refine the technical requirement documentation into a final form suitable for procurement action. Specifically:
    1. Identify a routing path in webIPS.

    2. Obtain a Security Review.

    3. Obtain a Technical Tier Review (if applicable).

    4. Initiate Privacy & Civil Liberties Impact Assessments (new systems, undergoing major modifications, and systems that are being re-certified. Note that this requirement is only for systems that contain SBU/PII ).

    5. Indicate whether Capability Maturity Model standards apply (Software Development only).

    6. Obtain a Section 508 Compliance Review.

    7. Work with a Contracting Officer to initiate an acquisition strategy and document the acquisition plan; develop the appropriate acquisition documentation, such as a Statement of Work (SOW) or technical specification, including a Independent Government Cost Estimate; Each file representing these items must be attached in webIPS. IRM 2.21.1.3.4 Note). See the link below to ensure that all relevant documents are attached to the requisition.

    http://awss.procurement.irs.gov/sai/docs/contents_of_a_req_pkg.doc

    Note:

    Requisitions may not be subject to all technical reviews.

    4. Submit the requisition for approval. IT requisitions initiated from Business Units must be routed to the appropriate ACIO service provider for review and approval.
    5. Maintain the required file copy of supporting documentation.
    6. Ensure for all purchasing transactions, a separation of duties exist between the requestor, and receiver.
  2. Diagram 1 - Parallel Process: Refine Technical Requirements

    Figure 2.21.1-1

    This is an Image: 37317001.gif

    Please click here for the text description of the image.

Work Request

  1. A Work Request (WR) is only needed when services are being requested on an existing contract that uses WRs. It is not needed for normal requisitions or contracts.
    http://irweb.irs.gov/Search_Search.aspx?search=wrts.web.irs.gov

Submitting a Completed Requisition for Process/Approval/Governance

  1. IRS Information Technology has developed a new improvement tool that was designed to streamline the requisition process that focuses on the customer/requestor, the approval paths and the approval processing time. The new streamlined process consists of five major process steps with only 3-5 webIPS approvers. See link below under Hot Topics/MITS Workshop Presentations: (click on IT Requisition Process/Process Improvement Strategy).http://sai.ds.irsnet.gov/sites/sai/p101-gap/p101/p101-home.aspx

  2. Requisition approvals are an integral part of the requisition process for purchasing IT products and services. Approvers are the individuals in the requisition approval path who review the requisition and, if the requisition is correct, release it to the next person in the approval path. All technical reviews are now done up front and not through webIPS to allow for a concurrent review;

    1. Tier Review (I-IV)

    2. 508

    3. Asset Management

    The responsibility is on the initiator to ensure that requirements are met;

    • Approver reviews are now in Functional Area (FA), one group box

    • Get up-to-date information from the website

  3. After completion of the required reviews and obtaining concurrences, complete the new IT Requisition Checklist to certify all appropriate programmatic and technical reviews have been satisfactorily completed. This Requisition Checklist is a tool to help users in preparing their requisition packages. IT requisitions initiated by BUs must be forwarded to the appropriate service provider for MITS 2-1-1 approval. See link below: (IT Requisition Checklist)https://portal.ds.irsnet.gov/sites/DCOSProcurement/p101/requisition/SitePages/Home.aspx

    Note:

    All attachments forwarded in Word must be saved as a WinZip file document using the Miscellaneous Format, prior to using the webIPS attachment function. Do not "cut & paste" the attachment into webIPS.

  4. All new Tier 1 and Tier 2 server hardware and/or software purchases MUST be approved by the Enterprise Operations (EOps) Investment Management Configuration Control Board (IMCCB). Therefore, an IMCCB Change Request (CR) must be submitted to and approved by the EOps IMCCB before those requisitions will be processed. The approved CR number and date of approval will be added to the comment section of the requisition in webIPS.

Tier Overview

  1. A Technical Tier Review can consist of an architectural, engineering, capacity, or standards review for the IT acquisition. There are four types of infrastructure Technical Tier Reviews as shown in the Table below. Each of the Technical Tier Reviews has different business processing rules and selection of the appropriate Technical Tier Review is based on the type of IT acquisition. Some acquisitions may require multi-Technical Tier reviews and concurrences.

Identification of the Appropriate Technical Tier Review

  1. The table below identifies Tier responsibility and the equipment/software under their review:

    If the acquisition is for Go to section: Definition
    Tier I
    Supercomputers and Mainframes
    2.21.1.3.7 Supercomputers and mainframe hardware and software, including peripheral subsystems used in a mainframe system environment.
    Tier II
    Minicomputers
    2.21.1.3.8 Minicomputers (i.e. computers usually containing multiple microprocessors, capable of executing multiple processes simultaneously, and may serve multiple users by way of a communications network) including hardware, software, and peripheral subsystems used in that environment. These systems typically include any hardware operating under a multi-user operating system, such as Windows, UNIX, and LINUX. Typically, these systems support centralized, high-volume enterprise applications. Hardware and software maintenance associated with the above items, including performing system backups, hardware upgrades and maintenance, operating systems upgrades and preventive maintenance tasks. Support for providing backups and daily operation of these systems. Windows-based networking servers: Primary Domain Controllers (PDCs), Backup Domain Controllers (BDCs), Windows Internetwork Servers (WINS), file and print servers and their backup systems; Windows-based application servers; and Microsoft Exchange messaging servers.
    Tier III
    Microcomputers
    2.21.1.3.9 Tier III - These systems include all workstation devices and any hardware operating under a Windows operating system. Including all hardware used in a desktop environment: Workstations functioning with a single-user (stand-alone) operating system including UNIX workstations that run single-user versions of UNIX and workstations that run any Windows operating system. This includes desktops, laptops and docking stations, monitors and keyboards associated with these devices, Personal Digital Assistants (PDAs), scanners, and printers. Tier III also includes new software, hardware and software maintenance associated with the above items, including performing system backups, hardware upgrades and maintenance, operating system upgrades and preventive maintenance tasks.
    Tier IV
    Data and Voice Telecommunications
    2.21.1.3.10 Data and voice (telecommunications) equipment, including switching equipment (i.e. private branch exchanges (PBXs); package switching equipment, etc., telecommunication networks and related equipment such as voice communications networks, local area networks, data communications networks; automatic call distributor/voice response units (ACDs/VRUs); modems, data encryption devices, fiber optics, terrestrial carrier equipment (multiplexers and concentrators); light wave, microwave, or satellite transmission and receiving equipment, telephonic equipment, and facsimile equipment.

Tier I Review

  1. Tier I consists of mainframes, computer-related hardware, software, maintenance, and related services. The scope will vary depending on the nature of the acquisition. The requestor shall follow 2.21.1.3.4 in obtaining IMCCB approval for new hardware and software being requested. This review should include an e-mail submission to the Asset Management Program Office (AMPO) via *IT Asset Management Review. Once approval has been given, include e-mail approval of attachment to requisition.

Tier II Review

  1. This review should include Tier II approval only via e-mail submission to the *IT T2 Requisition Review and the Asset Management Program Office (AMPO) via *IT Asset Management Review. Once approval has been given, include e-mail approval of attachment to requisition. Tier II and AMPO approvals are to be done on all requisitions (accept software for AMPO). See section: 2.21.1.3.12.

  2. This review should include Asset Management approval only via e-mail submission to the *IT Asset Management Review. Once approval has been given, include e-mail approval of attachment to requisition. AMPO approval is to be done on all requisitions (except software for AMPO). See section: 2.21.1.3.12.

  3. The requestor shall follow 2.21.1.3.4 in obtaining IMCCB approval for new hardware and software being requested.

Tier III Review

  1. Tier III consists of end-user computing related hardware, software, maintenance and related services, including desktops, laptops, and personal communications devices. This review should include e-mail submissions to the UNS Software Asset Management (SAM) group using the *IT T3 Software Review mailbox and the Asset Management Program Office (AMPO) to *IT Asset Management Review. When routing requisitions through the IPS approval path, please use TIER III REVIEW - T3REV. Once approval has been given, include e-mail approval as attachment to Requisition.

  2. Tier III acquisitions are handled directly by the Tier III owner. Ad hoc requests for acquisitions of this type may be received. If this occurs, visit OS GetServices

    http://getservices.web.irs.gov

  3. OS GetServices is a self service desk tool that provides the capability to report a computer, printer, fax, or any other IT-related problem. IT products and services can also be requested. Software requests must come through OS GetServices. The status of an existing request can be checked. OS GetServices web ticketing is available throughout the organization. The following web link provides more information:

    http://getservices.web.irs.gov

Tier IV Review

  1. Tier IV consists of telecommunications, including voice and data transmission hardware, software, and related services. Concurrence should be referenced in the Requisition Checklist. Exhibit 2.21.1-2 This review should include e-mail submissions to Asset Management Program Office (AMPO) to *IT Asset Management Review. Once approval has been given, include e-mail approval of attachment to requisition.

User and Network Services Additional Technical Reviews - Non Specific Tier related

  1. Asset Management Review (ASSETMGT) - The Asset Management Program Office (ASSETMGT) will review all IRS purchases for all IT hardware/software/maintenance, and related purchases to ensure proper barcoding, tracking, management and shipment confirmation. Support and Services contract requisitions are no longer required for review. An e-mail should be sent to the review mailbox at *IT Asset Management Review. Once approval has been given, include e-mail approval of attachment to requisition.

Enterprise Operations- Additional Technical Reviews - Non Specific Tier Related

  1. Enterprise Systems Management Review (ESMRVW) - The Enterprise Systems Management (ESM) organization will be included in the RTS approval path for any software product being purchased that provides automated support for use across the enterprise in any of the following Information Technology Service Management (ITSM) processes:

    ITSM Process Description
    Asset Management A software product that provides automated support to or facilitates the process of recording the entire life cycle of an IT asset from procurement to retirement.
    Incident Management A software product that provides automated support to or facilitates the process by which incidents are identified, controlled, documented, escalated and ultimately resolved and recorded.
    Problem Management A software product that provides automated support to or facilitates the process of identifying, analyzing, and documenting the underlying problems of incidents including root cause analysis.
    Change Management A software product that provides automated support to or facilitates the process of controlling changes to the infrastructure or any aspect of services, in a controlled manner, enabling approved changes with minimum disruption. This change may be related to the addition, modification or removal of approved, supported or baseline hardware, network, software, application, environment, system, desktop build or associated documentation.
    Configuration Management A software product that provided automated support or facilitates the process of identifying and defining Configuration items system, recording and reporting the status of Configuration Items and Requests.
    Release Management A software product that provides automated support to or facilitates the process by which a collection of changes which are tested and approved are introduced into the production environment.
    Service Level Management A software product that provides automated support to or facilitates the process of measuring the effectiveness and success and/or failure of a written agreement between a service provider and customer that documents agreed service levels for a service.
    Service Desk Any tools/products that would facilitate the work activity of the enterprise wide help for service desk function.

    Note:

    This review does not include Common Operating Environment (COE), above baseline software purchased for the desktop environment.

Security Review

  1. A purchase requestor must complete and submit the Security Compliance Review Checklist for IT Acquisitions as part of the process to obtain approval for any IT acquisition. The Security Compliance Review Checklist for IT Acquisitions must be included in the acquisition package and submitted to the Office of Procurement Contracting Specialist to show evidence of obtaining a security review and compliance. An IT acquisition is defined as the procurement of an IT product; hardware and/or software, telecommunications, equipment, and maintenance or service (including consulting services)

  2. The Security Compliance Review Checklist for IT Acquisitions documents compliance with Clinger-Cohen Act of 1996, also known as the Information Technology Management Reform Act (ITMRA), Government Information Security Reform Act (GISRA), Federal Information Security Management Act of 2002 (FISMA), OMB A-130, 123, and 127, Treasury Directive P 85-70, IRM 10.8.1, and IRM 2.21.1. These primary policy statements are augmented by other OMB, FAR, NIST, Treasury and/or IRS guidance and/or mandates, established internal systems, data and physical security policies, and technology standards

  3. A new self-certify feature has been added to the Security Compliance Review Checklist for IT Acquisitions. If you can self-certify, complete Sections A-E, include your signature, and submit the request to the IT Cybersecurity Self Certify Compliance Review Checklist mailbox with one of the following supporting documentation:

    • Statement of Work (SOW)

    • Request for Proposal (RFP)

    • Performance Work Statement (PWS)

    • Copy of existing fully issued contract/requisition

    • Copy of e-mail showing

    • Cyber prior approval of a security compliance checklist for this requisition

    • Last contract mod requisition/procurement order

  4. Cybersecurity will review the self-certify request and provide email confirmation, if approved. Cybersecurity may conduct an email conversation for clarification. Cybersecurity will complete its review within 10 business days upon receipt from the Requestor. Cybersecurity’s approval must be attached with the procurement requisition package to continue the process. If Cybersecurity does not approve the Security Compliance Review Checklist for IT Acquisitions, the requisition/purchase cannot go forward.

  5. If you are not able to self-certify, please complete Sections A-D and Sections F-H, include your signature and the Technical Point of Contact’s signature, and submit the request to the IT Cybersecurity Self Certify Compliance Review Checklist mailbox with one of the following supporting documentation:

    • Statement of Work (SOW)

    • Request for Proposal (RFP)

    • Performance Work Statement (PWS)

    • Copy of existing fully issued contract/requisition

    • Copy of e-mail showing

    • Cyber prior approval of a security compliance checklist for this requisition

    • Last contract mod requisition/procurement order

  6. Cybersecurity may conduct a telephone or email conversation for clarification. Cybersecurity will complete its security review and provide a response in Section I within 10 business days upon receipt from the Requestor. Cybersecurity’s approval must be attached with the procurement requisition package to continue the process. If Cybersecurity does not approve the Security Compliance Review Checklist for IT Acquisitions, the requisition/purchase cannot go forward.

  7. Include the FISMA Contract Language (IT Systems / Applications or Services), revised September 2016 in your Statement of Work. The FISMA Contract Language is posted at Procurement 101: https://portal.ds.irsnet.gov/sites/DCOSProcurement/p101/requisition/SitePages/Home.aspx

  8. It is the Requester’s responsibility to maintain a copy of the completed and signed Security Compliance Review Checklist for IT Acquisitions with your IT Requisition Package for future audit purposes.

  9. If you have questions regarding the Security Compliance Review Checklist, please contact the Cybersecurity POCs listed in Security Compliance Review Checklist for IT Acquisitions, Form 14775 posted at Procurement 101: https://portal.ds.irsnet.gov/sites/DCOSProcurement/p101/requisition/SitePages/Home.aspx

Privacy & Civil Liberties Impact Assessment (PCLIA)

  1. The Internal Revenue Service (IRS) recognizes the importance of protecting the privacy and civil liberties of taxpayers and employees. The vehicle for addressing privacy and civil liberties issues in a system is the Privacy & Civil Liberties Impact Assessment (PCLIA). The purpose of a PCLIA is to demonstrate that program/project managers, system owners, and developers have consciously incorporated privacy and civil liberties protections throughout the entire life cycle of a system. This involves making certain that privacy and civil liberties protections are built into the system from the beginning when it is less costly and more effective. As such, program/project managers, system owners, and system developersshould start preparing drafts of their PCLIAs as early as Milestone 0. The PCLIA must be submitted and approved by the Office of Privacy Compliance and Assurance (PCA) during Milestone 2.

  2. The PCLIA process is an analysis of how information in an identifiable form is collected, stored, protected, shared, and managed and also provides a means to assure compliance with all applicable laws and regulations governing taxpayer and employee privacy. One of these laws, the Electronic Government (E-Gov) Act of 2002, states that a PIA (PCLIA) must be conducted on systems. The Office of Management and Budget (OMB) released guidance on how to conform to the requirements of the E-Gov Act in Memorandum , (M) 03-22, “OMB Guidance for Implementing the Privacy Provisions of the E-Government Act of 2002”. For more information on PCLIAs please see IRM 10.5.2 - Privacy Compliance & Assurance (PCA) Program or the PCLIA web page

Capability Maturity Model Integrated - Software Development

  1. The Capability Maturity Model Integrated - Development (CMMI-DEV) is an increasingly important aspect of the acquisition process for services involving software development. If a technical requirement calls for software development, then the contractor is required to have a minimum rating of CMMI-DEV Level 2. If it cannot be determined that the acquisition is for software development or if the vendor is considered to be non-CMMI Level 2, contact Strategy and Planning, Strategic Supplier Management.

  2. Once it is determined whether or not the acquisition involves software development, such information must be indicated in the "Item Description" field of the webIPS record. Also, provide information about the nature of the software development. This action notifies the Contracting Officer that certain clauses must be incorporated into the contract. CMMI compliance must also be annotated in the IT Requisition Checklist.

Section 508 Compliance

  1. Effective June 25, 2001, the Federal government implemented Section 508 of the Rehabilitation Act of 1973, Amendments of 1998 (29 U.S.C. § 794(d)). Section 508 requires that the Federal government when developing, procuring, maintaining, or using electronic information technology (EIT), must ensure that the EIT allows Federal employees with disabilities to have access to and use of information and data that is comparable to the access to and use of information and data by Federal employees without disabilities. Section 508 also requires that individuals with disabilities, who are members of the public seeking information or services from a Federal department or agency, have access to and use of information and data that is comparable to that provided to the public without disabilities. Section 508 per IRS Information Technology individuals to file a complaint against Agencies that are alleged to have denied the comparable access and individuals are permitted to file a civil action. If substantiated, Agencies may be found liable for both attorneys' fees and/or injunctive relief; but not compensatory damages.

  2. The Federal Acquisition Regulation, Part 2.101, definitions –

    "Electronic and Information Technology (EIT)" has the same meaning as "information technology " except EIT also includes any equipment or interconnected system or subsystem of equipment that is used in the creation, conversion, or duplication of data or information. The term EIT, includes, but is not limited to, telecommunication products (such as telephones), information kiosks and transaction machines, worldwide websites, multimedia, and office equipment (such as copiers and fax machines.)

    "Information Technology" means any equipment, or interconnected systems(s) or subsystem(s) of equipment, that is used in the automatic acquisition, storage, manipulation, management, movement, control, display, switching, interchange, transmission, or reception of data or information by the agency.

  3. For any EIT requirement, you must go to the IRS Information Resources Accessibility Program (IRAP) web site and follow the instructions appropriate to your acquisition.

  4. When purchasing EIT supplies or services, requesters/requiring officials must: (1) establish their requirement, (2) compare the requirement against the Access Board's technology specific standard checklist, (3) select the applicable standard(s) and the standard's applicable provisions, (4) perform the necessary market research to determine if compliant supplies or services are commercially available, (5) prepare a determination, and (6) check http://irap.web.irs.gov for IRAP approval requirements. In the event the supplies or services are not commercially available or only partially available, the requester/requiring official must address these circumstances within the determination and, when applicable, attach the necessary exception documentation. If the requester/requiring officials make a determination based on Undue Burden, they must attach the necessary exception documentation. A Determination must be completed for each proposed procurement which contains the furnishing of any EIT supply or service.

  5. The Federal Acquisition Regulation (FAR), Part 39, implements Section 508 requirements with regard to contracts and Section 508 documentation.

Disclosure Review and Approval

  1. All IRS IT hardware, software, and files are designated as SBU based on the potentially sensitive information they contain. Accordingly, Treasury Regulation 301.6103(n)-1(d) requires all IT acquisitions to include appropriate Disclosure terms and Conditions in the contract.

  2. However requisitions will no longer require prior approval from Disclosure and Safeguards when contracts involve SBU information. Requisition initiators will answer questions designed specifically to determine the correct contract language. Additional changes include a Disclosure and Privacy Act tutorial, a questionnaire and automatic insertion of default clauses for solicitation and awards documents. webIPS will guide initiators through the process based on the answers they provide. WebIPS will automatically incorporate these clauses into solicitation and award documents.

  3. Post-award compliance contract reviews will be conducted to monitor conformity with Disclosure, Privacy Act and Safeguard policies and procedures. For more information on Disclosure requirements, see IRM 11.3.24 regarding Disclosures to Contractors.

Requisition Signatory Authority Approver

  1. The Requisition Signatory Authority Approver is the person who, under (MITS 2-1-1), has the authority to sign requisitions up to a specified dollar amount and ensure the requisition is fully compliant with IRS requirements prior to forwarding it to the Financial Plan Manager. The webIPS record for a requisition must include evidence that an individual who is authorized to approve the requisition, as specified in the Requisition Signatory Authority list has approved the requisition and the date of the approval. Additionally, IT requisitions must have the required reviewers and approvals before submission to Procurement.

  2. This evidence can be the actual processing of the requisition by the approver in webIPS or, if the approver does not use webIPS, a note should be inserted into the history record indicating the requisition was approved by (name/title/symbols of authorized approver and date approved). If you are unsure who your "authorized approver" is, refer to the Requisition Signatory Authority list and to gain access to all the Delegation Orders:

    http://mits.web.irs.gov/DirectivesMgmt/DirectivesDelegationOrders.htm

  3. In accordance with D.O. MITS 2-1-1 -- Approval of Information Technology (IT) Resources, an Executive who appoints an actor with lower funding approval authority other than their own, they must:

    • Formally document the acting authorization in a memo or e-mail

    • Identify a specific period for the actor's authority (time frame of the acting official)

    • The acting approver must retain the authorization memo or e-mail for audit purposes

    • Ensure approval authority is documented in requisition "Acting for (name) from (date) to (date)"

    Approval documentation should be attached to the requisition in webIPS.

Financial Plan Manager (FPM)

  1. The FPM is always the last person in the requisition approval path before the requisition is forwarded to Procurement. The FPM ensures appropriate funding is available, the correct Internal Order Code (IOC) and Spending Plan Item (SPI) is used, and the correct signature is on the requisition based on Delegation Order 2-1-1. An example of accounting string is: Fund, (12120919D), Plan Cost Center, (QCTF000), Functional Area, (9Z), Material Group Code (2616), IOC/SPI (zhara004).

Terms/Definitions

Acquisition Strategy – includes but is not limited to ensuring requirements can be fulfilled, providing for adequate competition/best value, and ensuring FAR social- economic goals can be met.

Approver – an individual in the requisition approval path who reviews the requisition and, if the requisition is correct, releases it to the next individual for approval.

Block Funding – Establishes funds availability for draw down for IT items to be purchased. IT purchases are not defined, but generally are of low dollar value. The draw down availability is typically based on prior year spend.

Business Justification – consists of the technical requirements of the acquisition, how it supports the organization’s business requirement, how the business requirement supports the Strategic and Program Plan, a basis of cost estimate, and any other relevant information.

Business Requirement – a gap in the performance of a business mission or function that can be addressed through purchase of proposed products and/or services.

Business Units – the major IRS organizational components which include LB&I, SB/SE, TE/GE, CC, AWSS, IRS Information Technology, NHQ, CI, C&L, W&I, TAS, and Appeals.

Business Systems Planner (BSP) – person responsible for ensuring that a Business Units' identified information technology business requirement is addressed in its Strategic and Program Plan.

Clinger-Cohen Act of 1996 – also known as the Information Technology Management Reform Act (ITMRA).

Disclosure Review – a review to eliminate instances involving unauthorized disclosures of or granting unauthorized access to SBU data or information being gathered, managed, or obtained as a result of the development of an information technology system. This review will be conducted on post award contracts and will not require a Disclosure official to be webIPS approval process.

E-300 Business Case – required by OMB in Part 7 of Circular A-11, "Planning, Budgeting, Acquisition, and Management of Capital Assets" to obtain funding for specific Electronic and Information Technology (EIT) projects.

Financial Plan Manager (FPM) – the person who ensures appropriate funding is available and the correct signature is on the requisition based on Delegation Order 2-1-1and is always the final person in the requisition approval path.

Government Cost Estimate (GCE) – the in-house developed costs projected by the government to secure contractual goods or services.

Non-IRS Information Technology Business Unit Funding – any resources for IT purchases originating from a Financial Plan other than IRS Information Technology (MITQ).

Personally Identifiable Information (PII) – is sensitive information that, either alone or in combination with other information, can be used to uniquely identify, contact, or locate a person. Unauthorized disclosure of PII places individuals at serious risk for identity theft and invasion of privacy. See Internal Revenue Manual - 10.8.1.3.1.1.2 for a more comprehensive definition.

Point of Contact (POC) - person responsible who initiates the documentation to refine technical requirements needed for the requisition process. Also serves as a technical contact for submitted requisitions. POC may be the Requestor.

Privacy & Civil Liberties Impact Assessment (PCLIA) –the PCLIA process is an analysis of how information in an identifiable form is collected, stored, protected, shared, and managed and also provides a means to assure compliance with all applicable laws and regulations governing taxpayer and employee privacy.

Requestor– person initiating the requisition in IPS. If the requestor is also the POC, the requestor is responsible for obtaining necessary agency expertise and resources to a task in order to ensure the Information Technology (IT) acquisition is ready for forwarding to Procurement. The Requestor may also be the POC.

Requisition Signatory Authority Approver – the person under (MITS 2-1-1) who has the authority to sign a requisition up to specified dollar amounts and who ensures that the requisition is fully compliant with IRS requirements prior to forwarding it to the FPM.

Security Review – ensures IT products or services being acquired are in alignment with the prevailing internal and external guidance and mandates, established internal systems, data and physical security policies, and technology standards.

Sensitive But Unclassified (SBU)– any information that requires protection due to the risk and magnitude of loss or harm to the IRS or the privacy to which individuals are entitled under 5 United States Code (U.S.C.) Section (§) 552a (the Privacy Act), which could result from inadvertent or deliberate disclosure, alteration, or destruction.

Section 508 Compliance Review– a review conducted with the specific purpose to determine compliance with Section 508 requirements for electronic information technology and the review of the requester's/ requiring official's market research for commercial availability. Federal agencies are required to develop, procure, maintain, and use EIT that provides comparable access to and use by employees and members of the public with disabilities, unless an undue burden would be imposed on the agency.

Strategic and Program Plan – describes mission priorities or business requirements of an IRS organization, whether these are new initiatives or a continuation of current initiatives.

Technical Tier Owner– IRS organizational area responsible for reviewing and approving a requisition for compliance with standards relating to specified hardware, software, and telecommunication equipment.

Technical Tier Review – consists of an architectural, engineering, capacity, or standards review for an IT acquisition.

Technical Point of Contact: (TPOC) -- The Program Office TPOC has the primary responsibility of providing technical assistance, input and direction to the CO and COR throughout the lifecycle of the contract. The TPOC will need to provide technical information regarding the requirement as well as obtain approvals required, if applicable, depending on the acquisition. The TPOC must provide the business justification, impact statement, complete any certification required such as Cyber Security Review, Privacy Impact, Capability Maturity Model (CMM), Enterprise Architecture (EA) Compliance and any other requirements needed in order to complete the acquisition process.

webIPS – a web-based version of the Request Tracking System (RTS) which provides a multitude of functions including the following: creating, routing, approving and funding requests for goods and services; status of requests; electronic receipt and acceptance; contract access to facilitate the building of requests; and enhanced document attachment functionality.

Requisition Checklist Template

  1. The revised Requisition Checklist is a guide/tool in preparing webIPS requisitions for all IT products and services, and has been designed to help the initiator/requester easily check that all requirements have been met in completing and processing requisitions. In addition, specific questions have been developed to assist in completing the requisition process.

  2. The checklist was structured to follow the flow of the actual requisition template. A cross check box is available to confirm completed. Listed below is the structured format as it relates to the requisition document.

    • Summary Tab

    • Funding Tab

    • Item Tab

    • Approval Tab

    • Attachment Tab

      • Continuing of Operations (COOP) Support Essential Function (Yes/No)

      • To indicate the COOP, you must respond either yes or no. The yes/no designation define the requirement in relation to Continuity of Operations (COOP) execution. A good test to apply in determining the COOP is; if the government is shutdown will anyone remain to monitor, receive, or use the contracted service or product. For non-procurement action types (i.e.PCI and MISCF) answer NO. For all non-procurement action types the Exception Code will be Lapse Code 7 (No exception applies). Lapse Code 7 does not require a justification. A more detailed description of each code can be found at Essential Contract Designations for Continuance during Furlough (Shutdown).

1. Link to Strategic Plan/Budget Approval Point of Contact

To determine that a business requirement is linked to, or supported by, the IRS Information Technology Strategic and Program Plan and budget, provide the Business Justification to the budget contact. Subsequently, the Budget contact provides you with the accounting string data required to initiate a requisition. In some cases, your requirements may be unfunded. While the requirement may still move forward, all involved parties must work together to effect a Financial Center Change, which realigns funding within an appropriation. In this case, there must be a clear statement from the IRS Information Technology Senior Executive Staff, Financial Policies function, that the requisition is unfunded, but that it is approved for further processing.