Y2K continuity plans for state unemployment agencies

Official letter (https://oui.doleta.gov/dmstree/uipl/uipl98/uipl_4698.htm):

U.S. DEPARTMENT OF LABOR
Employment and Training Administration
Washington, D. C. 20210
CLASSIFICATION: UI/Y2K
CORRESPONDENCE SYMBOL: TEUT
ISSUE DATE: September 16, 1998
RESCISSIONS: None
EXPIRATION DATE: September 30, 1999

UNEMPLOYMENT INSURANCE PROGRAM LETTER NO. 46-98
TO: ALL STATE EMPLOYMENT SECURITY AGENCIES
FROM: GRACE A. KILBANE, Director, Unemployment Insurance Service
SUBJECT: Year 2000 (Y2K) Business Continuity and Contingency Plans for State Employment Security Agencies (SESAs)

1. Purpose. To advise State Employment Security Agencies (SESAs) of the Department of Labor's (DOL) policy concerning Y2K Business Continuity and Contingency Plans; to provide guidance for developing business continuity and contingency plans; and to require the submission of plans for unemployment insurance (UI) critical business functions.

2. References. Employment and Training Administration (ETA) Handbook 336, 15^th Edition, State Agency UI Program and Budget Plans (PBP) Planning and Reporting Guidelines; U.S. General Accounting Office (GAO) Year 2000 Computing Crisis: Business Continuity and Contingency Planning document, published August, 1998; and UI Information Technology Support Center's Planning Guidance Document for Year 2000 Contingency Planning, published August 1998.

3. Background. Federal agencies are required to submit Y2K quarterly progress reports on mission critical systems to the Office of Management and Budget (OMB) which has Federal oversight responsibility for Y2K matters. For the purpose of these reports, all benefit systems, including the UI programs operated by SESAs, have been defined as mission critical systems. OMB has further required that contingency plans be developed for all mission critical business functions that might be impacted by Y2K failures. This requirement means that all SESAs must develop individual Y2K Business Continuity and Contingency Plans for critical business functions associated with the operation of their UI Benefits and Tax programs. SESAs' progress in developing these plans will be reported in the OMB quarterly reports.

   It is important to note that Y2K contingency planning is not an IT function, but represents a business function and should be developed by program personnel in conjunction with IT staff. Deciding what to do in case of automation failures requires an understanding of current business processes and day-to-day operations. The development of alternative processes that circumvent current automation support relies on expertise and program knowledge that primarily resides in the program operations areas of SESAs rather than in IT organizations. Additionally, assigning key Y2K staff the lead role in contingency planning might detract from crucial remediation efforts and may result in project failures.

4. Use and Scope of Plans. SESAs will activate contingency plans as necessary to ensure that critical UI business functions and key support processes are maintained in the event of Y2K failures. A SESA's plan must be coordinated with its Information Technology (IT) support teams responsible for Y2K compliance efforts and must be developed in concert with its risk management program. This will help assure an agency-wide approach to UI business continuity and reduce the potential need to implement these plans.

   Contingency plans will help ensure that SESAs continue to provide at least a minimally acceptable level of support in case of Y2K-related system failures. By identifying risks, developing mitigation strategies, and defining contingency processes that are independent of failed systems or interfaces, SESAs will be able to continue to take claims, pay claimants and collect employer UI taxes until systems are fixed and normal business operations are resumed.

   Y2K failures can occur internally within the SESA automation environment or can occur due to a host of external forces which are unpredictable and outside the control of the SESA. Internal system failures could occur due to delays in the SESA's Y2K remediation efforts or sudden loss of key agency or contractor staff. External failures could occur due to data-trading partners, e.g., banks, Y2K problems and/or unanticipated problems with vendor provided software.

5. Planning Methodology. A two-phase planning process, developed by the UI Information Technology Support Center (ITSC) in conjunction with their recently conducted "Year 2000 Contingency Planning Workshops," is the approach recommended by ETA. Phase I covers planning, business process evaluation, risk assessment (including both internal and external risks and threats) and strategy development. Phase II provides business continuity assurances by defining alternative solutions, performing trade-off analysis, selecting a contingency solution, establishing trigger points, developing a deployment and implementation plan to move to contingency operations, and developing a reinstatement and reconciliation plan to stop contingency operations and restart automated operations using the repaired systems or interfaces.

   Additional guidance on business continuity and contingency planning is contained in the UI ITSC's Planning Guidance Document for Year 2000 Contingency Planning and in GAO's Year 2000 Computing Crisis: Business Continuity and Contingency Planning document. These publications may be obtained from the UI ITSC's web site, located at

   http://www.itsc.state.md.us.

6. Plan Format and Instructions. SESAs will prepare two Y2K Business Continuity and Contingency Plans--one for UI Benefits and one for UI Tax. Each plan should identify critical functions, risks and threats, strategies to mitigate the identified risks and threats and the selected contingency solutions designed to support continued operations in the event of Y2K-related failures. At a minimum, each plan should contain three sections: (1) a list of core business functions, (2) a completed Business Continuity Planning Matrix, and (3) a detailed description of the selected contingency solutions as listed in the Business Continuity Planning Matrix. Comprehensive implementation plans should be developed by SESAs for those business functions most at risk from internal and/or external Y2K related failures.

   A list of Core UI Business Functions, developed by a National Office UI program team, is provided in Attachment 1 and represents a generic identification and prioritization of functions. The list is not inclusive and may vary from SESA-to-SESA. A sample Business Continuity Matrix is also included in Attachment 2.

7. Contingency Planning Workshops. The UI ITSC conducted three "Year 2000 Contingency Planning" workshops for SESA staff during June, July, and August. All SESAs, including those that have not sent staff to these seminars, are encouraged to have the contingency planning team members review and use the ITSC planning process and methodology materials presented at the seminars. Supporting documents and materials are available on-line at the UI ITSC web site.

8. Action Required. Administrators are to:

   1. Develop plans addressing the UI benefits program and submit a copy to the appropriate Regional Office for approval.

      • For the six SESAs already notified of being "at risk, " plans are due by October 1, 1998.

      For all other SESAs plans are due by November 20, 1998.

   2. Develop plans addressing the UI tax program and submit a copy to the appropriate Regional Office for approval by June 4, 1999.

9. Inquiries. Direct inquiries to the appropriate Regional Office.

10. Attachments:

    1. Core UI Business Functions

    2. Business Continuity Planning Matrix

Official Attachment 1 (https://oui.doleta.gov/dmstree/uipl/uipl98/uipl_4698a1.htm):

Attachment 1 to UIPL No. 46-98

Core UI Business Functions

NOTE: Because SESAs operate under varying State UI laws, there is a diverse array of systems and processes which, while similar, differ from SESA-to-SESA. Therefore, the list of critical and non-critical functions may vary among the SESAs. The list below represents a generic prioritization of functions which may be used as a starting point for developing SESA-specific lists.

UI Benefits: CRITICAL Functions:

• Initial Claims, intrastate, including Federal programs (UCFE/UCX)

• Initial claims, agent Interstate

• Initial claims, Liable Interstate

• Trade Readjustment Allowances (TRA), Disaster Unemployment Assistance (DUA)

• Monetary Determinations

• Non-monetary Determinations

• Weeks claimed, including receipt of certifications, payment authorizations and payments

• Claimant/employer appeals

• Appeals decisions processing

• Wage records/wage reporting

• Production and reporting of key economic data to USDOL, i.e., 538 and 539 reports, and elements of other essential required UI operational and budget reports. These elements are included in the following table.

List of Minimum Data Required to be Reported by States Operating Under UI Contingency Plans

NOTES: 1) See ET Handbook No. 401, Unemployment Insurance Reports Handbook, for report formats and cell contents; 2) It is assumed that States will be able to recover data and submit complete reports later; and 3) estimates may be reported.

UI Benefits: NON CRITICAL Functions:

• Benefit Payment Control

• Internal Security

• Benefit Charging

• Required Reports, not identified as CRITICAL.

• Eligibility Review

• Data Sharing

• Benefit Timeliness and Quality (BTQ/Benefits Accuracy Measurement(BAM)

• Workload Validation/Data Validation

UI Tax: CRITICAL Functions:

• Processing Wage Reports

• Maintenance of Wage Database

• Processing Tax Reports

• Employer account maintenance and cashiering

• Delinquent report control/collections

• Liability determinations/assignment of account numbers

• Assignment of tax rates

• Employer master file database

UI Tax: NON CRITICAL Functions:

• Field audits

• Tax performance system (TPS)

• FUTA Certification

• Data Sharing

• Required Reports, not identified as CRITICAL.

Official Attachment 2 (https://oui.doleta.gov/dmstree/uipl/uipl98/uipl_4698a2.htm):

Attachment 2 to UIPL No. 46-98

Business Continuity Planning Matrix

The sample matrix's columns are Business Function; Risk/Threat; Time Horizon to Failure; Business Priority (Risk Assessment, Impact, Score); Risk Mitigation Strategy (Strategy, Milestone Date, Action Org.); and Trigger Events/Dates and Alternative Solutions.

1. Initial Claims

• Risk/Threat: 1. Local Offices use PCs to input claims. PCs are old; not tested for Y2K compliance.
• Time Horizon to Failure: Jan. 1, 2000
• Business Priority: Risk Assessment .7 (high due to age of computers); Impact 8; Score 5.6.
• Risk Mitigation Strategy: Test all PCs; install BIOS fix if not compliant. Develop contingency solution and plan.
• Milestone Date: start: 9/1/98; end: 10/30/98.
• Action Org.: (List unit or organization responsible for mitigation efforts)
• Trigger Events/Dates and Alternative Solutions: If PC fix not completed by 11/30/98, then implement contingency solution plan.

2. Making mon/non-mon determinations

• Risk/Threat: 1. Requires access to central Benefits system, not Y2K compliant. Remediation efforts underway on system are behind schedule.
• Time Horizon to Failure: Jan. 1, 1999
• Business Priority: Risk Assessment .8 (labeled "at risk" by National Office); Impact 10; Score 8.0.
• Risk Mitigation Strategy: Closely monitor progress. If remediation schedule slips, have contractor add 3 more programmers. Develop full contingency solution and plan.
• Milestone Date: 10/15/98.
• Action Org.: (List unit or organization responsible for mitigation efforts)
• Trigger Events/Dates and Alternative Solutions: If Benefits system not compliant by Dec. 1, 1998, then implement contingency solution plan.

(#2 Continued)

• Risk/Threat: 2. Requires access to Wage Records. Database indexes have embedded dates and are not Y2K compliant. Remediation efforts are underway.
• Time Horizon to Failure: Jan. 1, 1999
• Business Priority: Risk Assessment .2 (work is almost completed); Impact 10; Score 2.0.
• Risk Mitigation Strategy: Closely monitor progress. Develop preliminary contingency solution.
• Milestone Date: 9/1/98 to finish testing.
• Action Org.: (List unit or organization responsible for mitigation efforts)
• Trigger Events/Dates and Alternative Solutions: If system not compliant by Dec. 1, 1998, then develop full contingency solution and implement.

3. (Continue with other business functions)

NOTES: All mission critical functions should be listed in the 1^st column. Risks or threats that might negatively impact the organization's ability to perform the listed function need to be included in the next column. There may be multiple risks associated with a function; if so, each needs to be listed in a separate row. The business priority score is used to determine the most critical areas to which resources should be applied to prepare for a potential failure. It is represented as a numerical score; the higher the number, the higher the priority. The business priority score is derived by multiplying two factors: (1) the risk assessment and (2) impact of a failure on the SESAs' ability to continue to do business. Risk assessment is the probability that the risk or threat will occur, and is expressed numerically, on a scale of 0 (low or no probability ) to 1.0 (highest probability). Impact also expresses a numeric range of values, from 1 to 10. It reflects the estimated degree of damage to the SESAs' ability to deliver service to its customers if the risk or threat occurs. The higher the value, the more adverse is the potential impact on service delivery. The business priority may change as the year 2000 nears. Thus, the Contingency Plan is a dynamic document, and must be reviewed and updated, as needed, to reflect new or changed information. Business priority scores will vary among the SESAs as individual situations vary greatly with respect to risks, threats and year 2000 remediation compliance efforts. Every risk/threat should have an associated mitigation strategy. The purpose of the strategy is to define a set of activities or actions that the organization can take to alleviate the likelihood of the occurrence of the risk/threat. The point in time at which the actions are invoked is then included in the Milestone Date column. The last column is used to list trigger events or dates that will invoke actions relating to the implementation of alternative contingency solutions. These solutions are invoked when the mitigation strategies fail and it is likely that a risk or threat will be realized, or when a Y2K-related failure actually occurs.