Provides valid risk mitigated solutions to security inquisitions.

Ensure all IT security policies and procedures are actively developed, and updated.

Respond to incidents quickly, and effectively to eliminate risks/threats.

Provide security advice to IRS constituents, and monitor IRS robust security program for any required modifications or enhancements.

Data Management Service and Support (DMSS): Provides reliable database and storage operations by pioneering improvements in data services.

Demand Management and Project Governance (DMPG):Leads the management and support of mainframe technologies.

Enterprise Computing Center (ECC): Manages EOps technology support throughout the production life-cycle of the service and application infrastructure. ECC also executes IT management processes and procedures established by IT controls and oversight.

Enterprise Server Division (ESD): Leads the management and support of mainframe technologies.

Enterprise Technology Implementation (ETI): Focuses on maturing EOps support for new or high-profile services such as Portals, SharePoint, Cloud, Office 365, Windows 2019, Oracle, WinOS Migration, Tech Insertion, Aged Infrastructure, E-Discovery, eRecords and Program Management Framework. Includes Technology Implementation Services and IRS Web Infrastructure Services

Infrastructure Services Division (ISD): Drives operational technology solutions through broad-based knowledge of EOps infrastructure and systems.

IT Operations Command Center (IT OCC): Serves as EOps’ first line of defense for Incident Management and Service restoration.

Security Operations & Standards Division (SOSD): Provides comprehensive oversight and management of EOps’ IT Security program.

Service Delivery Management (SDM): Provides program management in support of high visibility, strategic IT initiatives that require coordination within and / or outside EOps.

Server Support & Services Division (SSSD):

• Provisions servers for all platforms including the installation & configuration of COTS products
• Provides product support for IBM Rational tools, monitors server capacity & conducts performance testing
• Develops and manages standards for server Operating Systems and COTS products in the Tier 1 and Tier 2 environments
• Supports verification and validation of newly provisioned servers

Works in partnership with customers to improve the quality and deliver changes to IRS information systems products and services.

A key component of tax processing/filing season activities.

Provides development support for administrative systems related to workforce support, human capital, financial, and facilities.

Establishes and maintains rigorous contract and fiscal management, oversight, quality assurance, and program risk management processes to ensure that strategic plans and priorities are being met.

Maintains the effectiveness and enhance the integration of IRS installed base production systems and infrastructure while modernizing core business systems and infrastructure.

Provides quality assessment and assurance of Enterprise Life Cycle deliverables and processes.

Commissioner: Oversees and provides overall strategic direction for the IRS. The Commissioner’s and Deputy Commissioner’s focus is for the IRS’s services programs, enforcement, operations support, and organizations. Additionally, the Commissioner’s vision is to enhance services for the nation’s taxpayers, balancing appropriate enforcement of the nation’s tax laws while respecting taxpayers’ rights.

Deputy Commissioner Operation Support (DCOS): Oversees the operations of IRS-Wide Shared Services: Chief Financial Officer, Human Capital Office, Information Technology, Planning Programming and Audit Oversight and Privacy, and Governmental Liaison and Disclosure.

Chief Information Officer (CIO): The CIO leads Information Technology, and advises the Commissioner on Information Technology (IT) matters, manages all IRS Information Technology resources, and is responsible for delivering and maintaining modernized information systems throughout the IRS. Assisting the Chief Technology Officer (CTO) is the Deputy Chief Information Officer for Operations.

Application Development (AD) Associate Chief Information Officer (ACIO): The AD ACIO reports directly to the CIO; oversees and ensures the quality of: building, unit testing, delivering and maintaining integrated enterprise-wide applications systems to support modernized and legacy systems in the production environment to achieve the mission of the Service.

Deputy AD Associate CIO (DACIO): The Deputy AD ACIO reports directly to the AD ACIO, and is responsible for:

• Leading all strategic priorities to enable the AD Vision, IT Technology Roadmap and the IRS future state.
• Executive planning, and management of the development organization which ensures all filing season programs are developed, tested, and delivered on-time and within budget.

Compliance Domain

Corporate Data Domain

Customer Service Domain

Data Delivery Service (DDS) Domain

Delivery Management Quality Assurance (DMQA) Domain

Identity & Access Management (IAM) Domain

Internal Management Domain

Submission Processing Domain

Technical Integration (TI) Domain

Directs and oversees a unified cross-divisional approach to compliance strategies needing collaboration pertaining for the following:

Customer Service Domain’s applications and systems provide:
• Tax law assistance
• Taxpayer education
• Access to taxpayer account data
• Maintenance of modernized information systems that meet the customer’s needs for researching, updating, analyzing, and managing taxpayer accounts
 

Services to internal and external customers are provided through five primary means:
• Centralized Contact Centers (for telephone, written, and electronic inquiries)
• Self-service applications (via the telephone and Internet)
• Field Assistance (for walk-in assistance)
• Web Services
• Management of Taxpayer Accounts

IRM 2.5.3, Information Technology, System Development, Programming and Source Code Standards

IRM 2.5.4, Information Technology, System Development, Document Standards

IRM 2.5.6, Information Technology, System Development, Enhanced Software Development Life Cycle

IRM 2.5.8, Information Technology, System Development, Performance Measures

IRM 2.5.9, Information Technology, System Development, Peer Review

IRM 2.5.10, Information Technology, System Development, Function Point Standards

IRM 2.5.11, Information Technology, System Development, Analysis Techniques and Deliverables

IRM 2.5.12, Information Technology, System Development, Design Techniques and Deliverables

IRM 2.5.13, Information Technology, System Development, Database Design Techniques and Deliverables

IRM 2.5.14, Information Technology, System Development, Quality Assurance

IRM 10.5.8, Security Privacy and Assurance Privacy and Information Protection, Sensitive But Unclassified (SBU) Data Policy: Protecting SBU in Non-Production Environments

IRM 2.150.1, Information Technology, Configuration Management, Configuration Management Policy

IRM 2.150.2, Information Technology, Configuration and Change Management, Configuration Management

ISO/IEC 20000-1:2011, Information Technology - Service Management - Part 1: System Requirements, 9.2 Change Management

IT Infrastructure Library (ITIL) Service Transition, 2011 Ed., Chapter 4.2 Change Management

Capability Maturity Model Integration (CMMI) Version 2.0 for Development, CMMI institute released March 2018, website: https://cmmiinstitute.com

GAO-21-524T - Agencies Need to Develop and Implement Modernization Plans for Critical Legacy Systems report, April 2021

GAO-18-298T - Investment Performance and Risk Tax Processing report, June 2018

Interim Guidance memo, "IT-02-1121-0010" IT Decommission Policy

Identification and documentation of a change.

Analysis and evaluation of a Change Request.

Approval or disapproval of a Change Proposal.

Verification and validation, implementation and release of a change.

Emergency Change: A Request-For-Change (RFC) must be submitted for the change to occur as soon as possible as a (P1) or (P2) Incident Management ticket to the Change Analyst.

Standard Change: A Request-For-Change (RFC) must be submitted when an accepted solution from authority was approved in advance. This process pertains to repetitive or reoccurring changes.

Normal Change: A Request-For-Change (RFC) that requires a service change to a service or IT infrastructure. This is not an Emergency or Standard change, and is subject to a full change management review and Change Advisory Board review for authorization/rejection.

Proposer: The proposer must prepare a proposal and submit the proposal to the Change Analyst.

Change Analyst (CA): A Change Analyst is delegated by the Change Coordinator, and must manage/support the: plan, design, and build/test tasks of an RFC within the Change Management Life Cycle.

The CA must also perform the following:

• The impacted projects must be submitted as comments for the proposal to the responsible Change Analyst.
• The Change Analyst must review the proposal to determine the impacted projects.
• The Change Analyst must route the proposal with impacted projects for review.
• The Change Analyst must package the proposal as a Work Request (WR) and submit the WR to the Coordinator.
• The Change Analyst’s Frontline Manager must review and authorize the RFC after it is submitted by the initiating Change Analyst.

Change Manager (ChM): The Change Manager must support the Technical Authorization and Schedule and Approve Phases by reviewing the submitted Request For Change (RFC). The CM must ensure the RFC follows the correct workflow.

Change Coordinator (CC): The Change Coordinator must coordinate the RFC/WR assessment, planning, and performance of work completed by the technical team.

Change Authority (CA): The Change Authority is the approval group that must accept or reject the RFC/WR during the presentation to the Configuration Control Board (CCB). If the CA accepts the RFC/WR, the Chairperson must present the RFC/WR to the Committee or schedule the Proposer, Analyst, or Coordinator to present the RFC/WR.

Work Request (WR): For WR the following must happen:

• The Committee must reject or accept the WR
• If the Committee accepts the WR, the Analyst must package the WR with signatures, then submit the package to CCB SharePoint site
 

Change Approver/Change Advisory Board (CAB): The Change Approver or Change Advisory Board (CAB) consist of representatives from all IRS IT organizations/domains that must provide advice on the assessment, prioritization, scheduling of changes, and approval of releases.

The Requestor must prepare a memo requesting the Work Request.

The Requestor must submit the memo to the Configuration Controls.

The Coordinator must review the Work Request and submit the Work Request to the Sponsor, Configuration Control Board (CCB), for approval or denial.

The Government sponsor, CCB must either approve or deny the Work Request.

The Coordinator, within 15 working days, must notify the Requestor of a decision.

Identify the related standards document and, if applicable, the specific standard.

Explain and justify the request for a Work Request.

Identify any pertinent documentation.

Describe an alternative to the waived standard.

Identify a contact.

State whether the request was approved or denied or state whether additional time is required for a decision.

If additional time is required, then the notification must state the expected date of decision.

State an explanation to the Originator when a request is denied.

All activities for Quality Assurance (QA) must be planned.

Quality Assurance must be applied to all Application Change projects.

Software product quality (the conformance of products with standards and requirements) must be objectively validated.

Software service performance (the adherence of services with procedures and requirements) must be objectively verified.

Organizational units affected by QA activities must be informed of these activities and the results.

Noncompliance issues unresolved among organizational units must be organizationally elevated and resolved.

System Change and improvement activities must be coordinated across the organization.

Strengths and weaknesses of the Change processes used must be identified relative to the standard processes.

Organization-level Change processes, and improvement activities must be planned.

The customer’s business requirements must be agreed to and signed by all affected organizations.

Commitments among the Change organizations must be agreed to by affected organizations.

Development organizations must identify, track, and resolve issues.

Planning and coordination of requirements.

Peer review meetings must be planned.

Defects in software products must be identified by total number of major and minor defects found by all peer reviewers and removed.

Rework must be performed to resolve issues found.

A follow-up peer review meeting must be performed for reworked requirements artifact.

Exit Criteria - All defects and issues have been identified, corrected, and the product is accepted.

A standard Change and Maintenance process for the organization must be developed and maintained.

Information about the organization’s use of standard processes must be collected, organized, reviewed, and shared.

Software engineering tasks/activities must be defined, integrated, and consistently performed to produce software.

Software products must be kept consistent.

Project plans must be tailored from the IRS’s standard Change processes.

Projects must be planned and managed according to the IRS’s standard Change processes.

Establish the framework for organizations to make incremental process improvements.

Establish and maintain a set of organizational process assets.

Plan, implement, and communicate improvements.

Coordinate and deploy Process Change and improvement activities across the organization.

Develop new and updated processes and process assets.

System requirements allocated to software must be controlled to establish a baseline for software engineering and management.

When allocated requirements are changed, the plans, products, and activities associated with the software must be accordingly changed.

Software configurations management activities must be planned.

Corporate software products, identified as software configuration items, must be cataloged, controlled, and inventoried.

Access to, changes to, and distribution of configuration items must be controlled.

Organizational units involved in software configuration management activities must be informed of the status and content of software baselines.

Documented standards and procedures must be used in selecting software subcontractors and managing the subcontract.

Project managers and subcontractors must agree to their commitments to each other.

Project managers and subcontractors must maintain ongoing communication.

Project managers must track contractor’s actual results and performance against commitments.

Estimates must be documented and used in project planning and tracking.

Project activities and commitments must be planned and documented.

Project commitments must be negotiated between all managers involved in a project and the results of this negotiation must be documented.

Actual results and performance must be tracked against the project plan.

When actual results and performance significantly deviate from the plan, corrective actions must be taken and managed to closure.

Changes to project commitments must be agreed to by managers in affected organizational units.

Training activities are planned.

Identify training needed by the organization.

Obtain and provide training to address those needs.

Establish and maintain training records.

Assess training effectiveness.