2.150.5 Configuration Verification for IRS Applications (PSL and Non-PSL) Process

Manual Transmittal

March 17, 2023


(1) This transmits revised IRM 2.150.5, Configuration Verification for IRS Applications (PSL and Non-PSL) Process.

Material Changes

(1) IRM Identify Scope of CIs for Verification. Changed the scope of the process for IRS Tier II applications.

(2) IRM Conduct CI Verification and Updates. Removed the application interface verification activity.

Effect on Other Documents

IRM 2.150.5 dated April 26, 2021 is superseded


This IRM is applicable to all Information Technology (IT) organizations, contractors, and other stakeholders having responsibility for configuration management, oversight, and successful day-to-day operations of IRS IT enterprise hardware, software, and applicable documentation.

Effective Date


Nancy Sieger
Chief Information Officer

Program Scope and Objectives

  1. Purpose. This IRM supplements the configuration verification process under IRM 2.150.2 Configuration Management Process. This process specifically supports the configuration verification of IRS Applications (Premium Service List (PSL) and Non-PSL) and its Tier II server information to ensure that application to server relationships and select server attributes are accurate resulting in update to its configuration item (CI) information in the Information Technology (IT) organization’s configuration management database (CMDB). This process is a required activity for PSL applications to maintain data quality and integrity of the information that resides in the CMDB as part of Filing Season Readiness.

  2. Audience. This IRM is applicable to all IT organizations, contractors, and other stakeholders having responsibility for configuration, management, oversight, and successful day-to-day operations of the IRS IT enterprise hardware, software, and applicable documentation.

  3. Policy Owner. Demand Management & Project Governance (DMPG) Division, within Enterprise Operations (EOps) - IT.

  4. Program Owner. Governance & Resource Management Branch, within DMPG - EOps - IT.

  5. Primary Stakeholders. IT organizations having responsibility for ownership and management of IRS applications and infrastructure are practitioners of this process.

  6. Contact Information. To recommend changes or to make any suggestions to this IRM section, e-mail the IT CM Program Management Office: it.cm.process@irs.gov


  1. The PSL Revalidation (original process name) was incepted in 2015 and its purpose was to verify IRS critical systems, called PSL applications, information that were selected by the IT organization for premium incident response and service restoration services. It is a configuration verification activity performed as part of the Filing Season Readiness ensuring that PSL application information is accurate. The result of the PSL Revalidation is update to its CI record, such as application name, models, relationships, and services which are also consumed by other IT Service Management processes, such as Change, Incident, and Problem Management.

  2. The PSL Revalidation was expanded to Non-PSL applications to trigger configuration verification activities for all other IRS applications.

  3. This process will formally be called Configuration Verification for IRS Applications (PSL and Non-PSL) for the combined but separate efforts.


  1. The IRMs listed below establishes the authority for this process:

    • IRM 2.150.1 Configuration Management Policy

    • IRM 2.125.1 Change Management Policy

Roles and Responsibilities

  1. Each process defines at least one role. Each role is assigned to perform specific tasks within the process. The responsibilities of a role are confined to the specific process. They do not imply any functional standing within the hierarchy of an organization. For example, the process manager role does not imply the role is associated with or fulfilled by someone with functional management responsibilities within the organization. Within a specific process, there can be more than one individual associated with a specific role. Additionally, a single individual can assume more than one role within the process although typically not at the same time. The table below describes the roles and responsibilities for this process.

    Process Role Description
    Configuration Management (CM) Process Owner The CM Process Owner is the single point of contact for the process at the enterprise level and is accountable for the overall quality of the process, ensuring that the process is performed as documented and is meeting its objectives. The CM Process Owner’s responsibilities include sponsorship, design, review and continual improvement of the Process and its Metric. Specific responsibilities include-
    • Defines the overall scope, mission, goal, and objectives of the process

    • Ensures consistent execution of the process across the IT organization

    • Ensures that the process, roles, responsibilities and documentation are regularly reviewed and audited

    • Reports on the effectiveness of the process to senior management

    • Accountable for implementation and review of improvement actions

    • Ensures that sufficient resources are in place to support implementation of the process

    • Ensures all relevant staff have the required training in the process and are aware of their role in the process

    • Ensures that the process is in alignment with the process automation tool(s)

    • Resolves any process and cross-functional (departmental) issues

    CM Process Manager (IT CM PMO) The CM Process Manager supports the CM Process Owner and is responsible for the operational management of the process. The Process Manager’s responsibilities include planning and coordination of all activities required to execute, monitor and report on the process. Specific responsibilities include–
    • Designs, develops, and manages improvements to the process; including plans, principles and its implementation

    • Provides training and communication on the standards, policy, and process to CM stakeholders

    • Plans, facilitates and organizes reviews, assessments, and audits on the process and CMDB with the Configuration Auditor

    • Plans and manages the alignment of the CM tools with the process; including evaluating CM tools and their design, requirements, proposed changes, and implementation

    • Develops, coordinates, and maintains the interfaces to other processes.

    • Defines process metrics for measurement, reporting, and improving the process

    • Escalates any issues with the process

    • Maintains scope of the process, function, and CIs that are to be controlled, and information that is to be recorded

    • Ensures that configuration data is available when and where it is needed to support other IT processes

    • Agrees on the structure of the CMDB, including CI types, naming conventions, required and optional attributes and relationships

    • Designs and generates configuration status reports; including management reports

    Configuration Item (CI) Owner The CI Owner is accountable for all activities that directly affects their CI(s). This role is also responsible for all CM process activities associated with the maintenance and support of the CI. Specific responsibilities include –
    • Ensures that all their CIs are recorded, and the associated attributes and relationship information is accurate

    • Ensures configuration audits are performed on the CMDB

    • Provides input to the CI Librarian/ Analyst into what attributes and relationships need to be tracked within the CMDB

    • Accountable for correcting errors associated with their CIs

    CI Owners may be Application Owners, Project Owners, Server Owners, or Support Groups.
    Configuration Item (CI) Librarian/Analyst (Enterprise Configuration Management System Team)) The CI Librarian/Analyst supports the CM Process Manager and CI Owner and is responsible for supporting, maintaining, controlling, and updating a specific CI or CIs. Specific responsibilities include –
    • Controls the receipt, identification, storage and withdrawal of all supported CIs, including archives of superseded CIs

    • Identifies and records the CIs in the CMDB, and determining relationships

    • Ensures Data Model is accurate

    • Supports generation of status reports on various CMDB parameters and requests

    • Maintains status information on CIs and provides this as appropriate to stakeholders

    • Assists with conducting configuration audits, performing internal audits and validating exceptions

    • Identifies, records and submits incidents relating to CIs

    • Records and maintains CI Types (within scope) in the CMDB

    • Discovers, reconciles, and updates CI records in the CMDB

    • Validates accuracy of CMDB data and report discrepancies

    • Creates and maintains the service and application models for CIs

    • Provides input to the process scope and procedures.

    PSL Process Manager (Service Restoration Team) Responsible for development, management, and maintenance of the PSL Process and facilitating review and approval of proposed applications to the EOps Governance Board as a Premium Service application.
    SSF Team (Infrastructure Asset Management Team) Role in the SSF Process responsible for coordinating and implementing SSF change request submitted by CI Owners to update the application name and SSF attributes in Asset Management database and IRS Tier II servers.
    EOps Governance Board Responsible for approving/disapproving proposed applications in the PSL Process by CI Owners.

Program Management and Review

  1. The IT CM Program Office (PMO) shall manage and evaluate the process based on the following guiding principles:

    1. Process Management. Configuration Management will have a single Process Owner and a separate Process Manager, responsible for implementing and ensuring adherence to the process. The process will be reviewed regularly to ensure that it continues to support the business requirements of the enterprise. Process metrics will be focused on providing relevant information as opposed to merely presenting raw data.

    2. People. Roles and responsibilities for the process must be clearly defined and appropriately staffed with people having the required skills and training. The mission, goals, scope and importance of the process must be clearly and regularly communicated by upper management to the staff and business customers of IT. All IT staff (direct and indirect users of the process) shall be trained at the appropriate level to enable them to support the process. It is imperative that people working in, supporting or interacting with the process in any manner understand what they are supposed to do. Without that understanding Configuration Management will not be successful.

    3. Process. Modifications to Configuration Management must be approved by the Process Owner. The design of the process must include appropriate interfaces with other processes to facilitate data sharing, escalation and workflow. The process must be capable of providing data to support real-time requirements as well as historical/trending data for overall process improvement initiatives. The process must be fully documented, published and accessible to the various stakeholders of the process. The process will be reviewed on a periodic basis to ensure it continues to support organizational goals and objectives (continuous improvement). The process must include Inputs, Outputs, Controls, Metrics, Activities, and Roles and Responsibilities along with documented process flows. The process will be kept straight forward, rational, and easy to understand. The process must meet operational and business requirements.

    4. Technology and Tools. All tools selected must conform to the enterprise architectural standards and direction. Existing in-house tools and technology will be used wherever possible, new tools will only be entertained if they satisfy a business need that cannot be met by current in-house tools. The selection of supporting tools must be process driven and based on the requirements of the business. Selected tools must provide ease of deployment, customization and use. Automated workflow, notification and escalation will be deployed wherever possible to minimize delays, ensure consistency, reduce manual intervention and ensure appropriate parties are made aware of issues requiring their attention. Technology and tools should be used to augment the process capabilities, not become an end themselves.

Program Controls

  1. Program controls are driven by the policies and guiding principles on how the process will operate.

  1. Controls provide direction on the operation of processes and define constraints or boundaries within which the process must operate.

    Name Description
    CM Policies Policies and mandates for management and control of CIs.
    Change Management Policies Policies and mandates for change control of CIs.
    Enterprise Architecture Mandates Requirements and mandates for all IRS applications to be registered and updated in the As-Built-Architecture.
    Scope The scope for this process is limited to IRS business applications supported by Tier II servers.
    Baselines Documented agreed descriptions of the attributes and/or specifications of a CI, at a point in time, which serves as the basis for defining change.
    Configuration Verification The frequency of configuration verification to maintain the integrity of the CI and its attributes and relationships.
    Configuration Reports The frequency and distribution for regularly produced configuration management reports on the status of CIs.
  1. Metrics are used for the quantitative and periodic assessment of a process. They should be associated with targets that are set based on specific business objectives. Metrics provide information related to the goals and objectives of a process and are used to take corrective action when desired results are not being achieved and can be used to drive continual improvement of process effectiveness and efficiency.

  2. Management will regularly set targets for process performance, gather quantifiable data related to different functions of this process, and review that data to make informed decisions and take appropriate corrective action, if necessary. All Measurements will have a defined data dictionary, map to the organizational strategic goals, and be documented in a Process Measurement Plan.

  3. Enterprise and local Configuration Management processes, including Configuration Management tool owners, must produce metrics and measurement reports to measure the effectiveness and efficiency of the Configuration Management process.

Tailoring Guidelines
  1. This process will not be tailored.


  1. The tables in the Terms/Definitions and Acronyms lists commonly used terms and acronyms in this IRM.

Terms and Definitions
  1. This table lists commonly used terms for this process.

    Term Definition
    Application Collection of software programs that automates a business function and its data provided by a taxpayer or third party to the IRS regarding the applicant's status. Additional descriptions are listed below:
    • An IT component of a system that utilizes IT resources to store, process, retrieve or transmit data or information using IT hardware and software.

    • Each Application may be part of more than one IT Service.

    • An Application runs on one or more servers or clients.

    • Its functionality supports business processes.

    • Interactive applications support business end users directly.

    • Batch applications manage data, and generate reports, etc., as part of a business process.

    • Applications include IRS-specific functionality in support of business requirements as well as generic end-user functionality.

    • Generic functionality includes common desktop applications its functionality include highly complex capabilities that are nevertheless common to many different types of enterprise, such as accounting or customer- relationship-management capabilities.

    • Generic capabilities are typically provided by COTS applications, whereas IRS-specific capabilities generally involve custom-developed applications.

    As-Built-Architecture Represents the IRS’ Current Production Environment (CPE) with business applications, external systems, and external trading partners. It also includes interfaces, key attributes, and information related to Privacy and Civil Liberties Assessments. The ABA allows Business Analysts and Information Technology (IT) professionals to view the CPE from both technical and business perspectives using IRS’ Enterprise Life Cycle’s (ELC) Six Domains of Change, to see interrelationships between technological and business domains, and get information necessary to make informed decisions.
    Configuration Verification Configuration Management activity responsible for confirming that configuration management records and CIs are complete, consistent, and accurate.
    Configuration Management Database (CMDB) A CMDB is a database that contains all relevant information about the hardware and software components used in an organization. It includes the components, the IT services they support and the relationships between those components. A CMDB provides an organized view of configuration data and a means of examining that data from different perspectives.
    Non-Premium Service List (Non-PSL) Applications that are not in the PSL are called Non-PSL. These applications do not have a distribution system for inviting service providers and management to an escalation. E-mails are sent to service providers selected by the person taking the IMR role. The Service Operations Specialist (SOS) send the emails. Non-PSL escalations are set to a lower priority than PSL escalations. Non-PSL tickets are worked as capacity permits.
    • A SOS will leave a Non-PSL escalation if a PSL outage requires an escalation and IMS doesn’t have the capacity to work both.

    Premium Service List (PSL) PSL applications are listed on the Premium Service List (PSL) and are linked to a distribution system which utilizes Derdack for automated calls/invites and e-mail distribution lists to an escalation. The SOS initiate the Derdack system and send the e-mail. This enables the IT Operations Command Center (ITOCC) to contact service providers and management quickly with accountability. Incident Managers of Record (IMR) are also trained and used to facilitate Assessment, Technical Service Restoration Team (SRT), and Management SRT calls for PSL applications.
    • PSL outages are the SOS highest priority.

    Sub-application Is a part of a larger application (please refer to Application definition). Additional descriptions listed below:
    • Its functionality supports business processes.

    • Collection of one or more software programs that automates a business function.

    • Can reference other sub-applications to any depth.

    Server Signature File (SSF) Process The SSF delivers valuable server data to Configuration Management System tools providing additional insight into IRS Enterprise Operations infrastructure. It validates server attributes (Project, GSS, and ENV), ensure data quality and integrity, and deploy the SSF file to existing and new EOps Tier II servers.
    Tier 1 System Supercomputers and Mainframes Supercomputers and mainframe hardware and software, including peripheral subsystems used in a mainframe system environment.
    Tier II System Minicomputers and Servers 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
  1. This table lists commonly used acronyms in the Configuration Management process.

    Acronym Description
    ABA As-Built-Architecture
    AM Asset Manager
    CI Configuration Item
    CM Configuration Management
    CMDB Configuration Management Data Base
    CPE Current Processing Environment
    CR Change Request
    ENV Environment
    GSS General Support System
    KISAM Knowledge, Incident, Service Desk, and Asset Management
    PSL Premium Service List
    SSF Server Signature File
    UCMDB Universal Configuration Management Database

Related Resources

  1. The following lists the primary sources of references used in the development of the CM process.

    • IRM As-Built-Architecture Architecture

    • IRM 2.17.1 Infrastructure Currency Policy for Software

    • IRM 2.125.2 Change Management Process

    • IRM 2.150.2 Configuration Management Process

    • Change Management Procedure

    • Server Signature File (SSF) Standard Operating Procedure

    • How to Generate Tier II Server List from the Configuration Management Database

    • How to Open a Standard or Normal SSF CR or RfC

    • How to Complete the Validation Process for Your PSL Application(s)


  1. Process training involves training all stakeholders about key processes that are crucial for an organization to deliver business objectives. Training provides clarity to employees on a set of procedures that needs to be carried out as part of the process and the best possible way to do them. Listed below are the training resources available for this process:

    • Configuration Management (CM) Overview, ITM Course #23279

    • Change Management Process Overview, ITM Course #43161

    • Change Analyst/Change Initiator Role Training

    • Change Coordinator Training

    • Change Manager Role Training

Process Workflow

  1. A process workflow consists of Activities and Tasks, Inputs and Outputs, Roles, and Flow Diagrams. It describes the tasks, procedural steps, organizations or people involved, required input and output information, and tools needed for each step of the process.

Main Process Diagram

  1. The Main Process Diagram illustrates the key process activities and process interfaces for Configuration Verification for IRS Applications (PSL and Non-PSL).

    Figure 2.150.5-1

    This is an Image: 75426001.gif

    Please click here for the text description of the image.


  1. Process inputs are used as triggers to initiate the process and to produce the desired outputs. Users, stakeholders or other processes provide inputs. The following is a list of inputs for this process:

    Name Description Supplier
    Premium Service List List of select systems critical to the mission of the IRS and approved for Premium Services for Incident Management response and escalation services. PSL Process
    Asset Manager (AM) Project Table List of Programs, Projects, Applications, COTS, and Services derived from the SSF Process. SSF Process
    ABA Application Report List of CPE Applications registered in the ABA. ABA
    CMDB Server Report List of Tier II servers associated with the PSL application. UCMDB


  1. Each process produces tangible outputs. These outputs can take the form of products or data and can be delivered to a user or stakeholder or they can be used as inputs to other processes. Outputs are measurable in terms of quantity and quality.

    Name Description Recipient
    Verified and Updated CI Information Verified and updated application to server relationships, server inventory, and server attributes. Application Owner

    CM Process Manager
    Status Report Status of configuration verification activity and results. Stakeholders
    SSF/PSL Change Request (CR) A SSF/PSL CR is the record of a Change proposal or corrections to the SSF attributes (Project, GSS, and ENV) that is worked through the Change Management process. Change Coordinator

    Change Analyst


  1. An activity is a major unit of work to be completed in achieving the objectives of the process. A process consists of a sequence of related activities that transforms inputs into outputs and performed by the roles defined in the process. Activities are measurable in terms of efficiency and effectiveness. The following activities for this process are described below and corresponds to the high-level process flow diagram above.

    1. Establish Initial Scope of Application CIs for Verification. This activity establishes the initial scope of CIs for the process.

    2. Identify CI Ownership and Finalize Scope. This activity identifies CI ownership and finalizes the scope.

    3. Plan and Prepare Project Requirements. This activity establishes the plan, schedule, resources, roles/responsibilities, reporting, and expectations including preparing the tools and documentation to support the process.

    4. Conduct Application Verification and Updates. This activity implements the verification process including use of the SSF Process to correct the discrepancies.

    5. Generate Report and Close Out. This activity is responsible for reporting out the results of the activities and close out.

Procedures for Configuration Verification for IRS Applications (PSL and Non-PSL)

  1. This procedure describes the tasks, roles, and responsibilities for the process.

Establish Initial Scope of Application CIs for Verification
  1. This activity establishes the initial scope of application CIs that will be verified for its relationships, server inventory, and server attributes. The following tasks, performed by the IT CM PMO, are described below.

    1. (1) Identify Application CIs for Verification.

      1. For PSL Applications, obtain and review latest update of the Premium Service List.


        PSL Applications are derived from the Premium Service List that is maintained by the PSL Process Manager.

      2. For Non-PSL Applications, obtain and review latest update of the AM Project Table and exclude PSL applications.


        The AM Project Table contains programs, projects, applications, software products, and other data types such as services and technical/support groups. The SSF Process extracts select data from the AM Project Table to create the SSF Project Table for its use. For reference, the SSF Project Table will also be called the AM Project Table.

      (2) Correlate and Select Tier II Applications.

      1. For PSL Applications, correlate the Premium Service List against the AM Project Table and select only those supported by Tier II servers.

      2. For Non-PSL Applications, correlate the AM Project Table against the Applications (All) Report from the As-Built-Architecture (ABA) and select only those supported by Tier II servers. Select only a sample of applications supported by Tier II servers to manage the scope of work. For example, select applications from a particular ACIO, Filing Season Application, etc.


        The ABA applications may be supported on IRS Tier I or Tier II systems, Managed Service Provider, or External Trading Partners.

      (3) Verify Tier II Servers in the CMDB.

      1. Verify application is supported by Tier II servers.

      2. Exclude applications not supported by Tier II servers.

      (4) Establish Initial Scope.

      1. Establish initial scope for applications that are supported by Tier II servers.

Identify CI Ownership and Finalize Scope
  1. This activity identifies or verifies CI Ownership and finalizes the scope for the process. The following tasks, performed by the IT CM PMO, are described below.

    1. (1) Identify CI Ownership.

      1. Identify and/or verify CI Ownership (i.e., Application Owner and Manager) information to ensure that correct individuals are the ones that will be responsible for the verification activities.


        Source of CI Ownership information is in the ABA. Application Owners are called Content Providers and Managers (i.e., Frontline Manager and Senior Manager).

      2. If no CI Ownership is identified, exclude the application from the scope.

      (2) Finalize Scope.

      1. Establish final list of applications supported by Tier II servers with CI Ownership information.

Plan and Prepare Project Requirements
  1. This activity establishes the plan, schedule, resources, roles/responsibilities, reporting, and expectations including preparing the tools and documentation to support the process. The following tasks, performed by the IT CM PMO, are described below.

    1. (1) Establish Administrative Process for Verification.

      1. Define and design administrative process (manual or automated) to conduct and collect verification results. For example, using desktop tools (e.g., Excel, Access, Email) to manually record or SharePoint solution to automatically record and self-certify verification activities.


        For SharePoint solution, identify roles and permissions for each Application Owner. The existing SharePoint solution for this process is called the PSL Revalidation Portal.

      (2) Identify Key Resources.

      1. Identify and verify support teams that may have a role in supporting the process. For example, those responsible for change management process (SSF Team), PSL process (SOS Team), and CMDB (ECMS Team).

      2. Identify supporting tools, such as KISAM and UCMDB.


        For the UCMDB, review and revise, if necessary, the server report template called “PSL Revalidation”. The server report template is applicable for both PSL and Non-PSL applications.

      (3) Establish or Update User Guides.

      1. Establish or update User Guides to support the process. The following existing user guides are:
        How to Complete the Validation Process for Your PSL Application(s)
        How to Generate Tier II Server List from the Universal Configuration Management Database
        How to Open a Standard or Normal SSF CR or RfC

      (4) Establish Measurement and Status Reporting Requirements.

      1. Determine what to measure and report.

      2. Identify data to measure and report.

      3. Design and establish measurement and report template.

      4. Determine reporting frequency.

      (5) Establish Project Schedule.

      1. Determine project start and end date, including extended deadlines, if necessary.


        For PSL applications, align schedule with EIC.

      2. Determine schedule for Project Pre-Kick Off Meeting and Kick Off Meeting.

      3. Determine schedule for status reporting.

      Conduct Pre-Kick-Off Meeting.

      1. Develop briefing materials for Project Pre-Kick Off Meeting and Kick-Off-Meeting.

      2. Define roles, responsibilities, and expectations

      3. Schedule and conduct Project Pre-Kick Off Meeting with support teams.

Conduct Application Verification and Updates
  1. This activity is responsible for establishing and implementing the verification activities to verify and certify the Application CI information.

    Conduct Project Kick-Off Meeting (IT CM PMO).

    1. Schedule and conduct Project Kick-Off Meeting.

    2. Conduct training, as necessary.

    3. Prepare and distribute meeting minutes.

    Conduct Verification Activities (CI Owners).

    1. Review and verify the following information for accuracy for each PSL application in the CMDB.
      (1) Server inventory
      (2) Server attributes (Project, GSS, and ENV)

    2. Identify discrepancies.
      (1) Server inventory is not correct (e.g., missing server or incorrect server)
      (2) Server host name is not correct
      (3) Server attribute is not correct (i.e., Project, GSS and ENV assignment)


      Refer to the instructions, How to Complete the Validation Process for Your PSL Application(s) and How to Generate Tier II Server List from the Universal Configuration Management Database for this step.

    Correct and Re-verify the Data, if applicable (CI Owners).

    1. Complete the SSF CR Initiator Worksheet Template to record the corrections.

    2. Submit a Change Request (CR)..
      (1) For the Title, use “FYxx PSL CR - “Project Name” to separate the PSL CR from regular SSF CR.
      (2) Follow the rest of the instructions to complete the form.


      Refer to the instructions, How to Open a STANDARD or NORMAL SSF CR or RfC for this step. Only corrections to existing records should be made, not changes. A separate SSF CR must be submitted for changes to the record. The objective of this process to review and correct the record to reconcile with the CI owner’s administrative record.

    3. Record the PSL CR # in the PSL Revalidation Portal


      The Application Owner must monitor the status of their PSL CR and ensure that it is implemented and closed.

    4. Verify updates in the CMDB once the corrections have been implemented.

    Certify the Verification (CI Owners).

    1. Record the date the verification was completed in the PSL Revalidation Portal.


      The verification process is complete once the date of validation is recorded, not when the PSL CR is closed. The process to complete the PSL CR is separate from the verification process.

    Conduct Follow-Up, as needed (IT CM PMO).

    1. Review verification status and identify those that have not completed the process.

    2. Determine if assistance is needed to initiate or complete the process.

    3. Send scheduled reminders to those that have not completed the process.

Generate Report and Project Close Out
  1. This activity is responsible for summarizing and reporting out the results of the verification activities and project close out. The following tasks, performed by the IT CM PMO, are described below.

    Gather and Collect Data.

    1. Gather and collect results for each defined reporting period.


      Data collected from the defined administrative process (e.g. SharePoint), including from other tools such as KISAM for the PSL CR information.

    Analyze and Summarize Results.

    1. Aggregate data based on defined reporting requirements in the report template.

    2. Analyze and summarize cumulative results.

    3. Develop charts and tables to support the analysis and performance measurements.

    Generate Report and Project Close Out.

    1. Generate and release scheduled status and measurement reports to all stakeholders.

    2. On project close out -
      (1) Conduct final summary and release final report.
      (2) Release all support teams.
      (3) Archive all resource materials.
      (4) Remove CI Owner permissions to update PSL Revalidation Portal from updates.