Description and Authority Services (DAS)

Security Categorization: Low

Information System Contingency Plan (ISCP)

Date: April 15, 2020Version #: 3.0

Prepared by

National Archives and Records Administration8601 Adelphi Road

College Park, MD 20740

Table of Contents

Plan Approval.............................................................................................................................................................1

1.0 Introduction.....................................................................................................................................................21.1 Background.................................................................................................................................................2

1.2 Scope...........................................................................................................................................................21.3 Assumptions................................................................................................................................................2

2.0 Concept of Operations....................................................................................................................................32.1 System Description.....................................................................................................................................3

2.2 Overview of Three Phases..........................................................................................................................42.3 Roles and Responsibilities..........................................................................................................................4

3.0 Activation and Notification.............................................................................................................................53.1 Activation Criteria and Procedure..............................................................................................................5

3.2 Notification.................................................................................................................................................63.3 Outage Assessment.....................................................................................................................................7

4.0 Recovery.........................................................................................................................................................74.1 Sequence of Recovery Activities................................................................................................................7

4.2 Recovery Procedures..................................................................................................................................84.3 Recovery Escalation Notices/Awareness....................................................................................................8

5.0 Reconstitution.................................................................................................................................................85.1 Validation Data Testing..............................................................................................................................8

5.2 Validation Functionality Testing................................................................................................................85.3 Recovery Declaration..................................................................................................................................8

5.4 Notifications (users)....................................................................................................................................95.5 Cleanup.......................................................................................................................................................9

5.6 Data Backup................................................................................................................................................95.7 Event Documentation..................................................................................................................................9

5.8 Deactivation................................................................................................................................................9APPENDIX A: PERSONNEL CONTACT LIST....................................................................................................11

APPENDIX B: VENDOR CONTACT LIST...........................................................................................................12APPENDIX C: DETAILED RECOVERY PROCEDURES....................................................................................13

APPENDIX D: ALTERNATE PROCESSING PROCEDURES.............................................................................14APPENDIX E: SYSTEM VALIDATION TEST PLAN..........................................................................................15

APPENDIX F: DIAGRAMS (SYSTEM AND INPUT/OUTPUT).........................................................................16APPENDIX G: HARDWARE AND SOFTWARE INVENTORY.........................................................................17

APPENDIX H: INTERCONNECTIONS TABLE...................................................................................................18

APPENDIX I: TEST AND MAINTENANCE SCHEDULE...................................................................................19APPENDIX J: ASSOCIATED PLANS AND PROCEDURES...............................................................................20

APPENDIX K: BUSINESS IMPACT ANALYSIS.................................................................................................21APPENDIX L: DOCUMENT CHANGE PAGE......................................................................................................22

Plan Approval

In accordance with National Archives Records Administration’s (NARA) contingency planning policy, I hereby affirm that the contingency plan is complete and has been tested sufficiently. The designated authority is responsible for continued maintenance and testing of the ISCP.

As the designated authority for the Description and Authority Services (DAS) system, I hereby certify that the information system contingency plan (ISCP) is complete, and that the information contained in this ISCP provides an accurate representation of the application, its hardware, software, and telecommunication components. I further certify that this document identifies the criticality of the system as it relates to the mission of NARA, and that the recovery strategies identified will provide the ability to recover the system functionality in the most expedient and cost-beneficial method in keeping with its level of criticality.

I further attest that this ISCP for DAS will be tested at least annually. This plan was last tested on March 25, 2020; the test, training, and exercise (TT&E) material associated with this test can be found in Xacta. This document will be modified as changes occur and will remain under version control, in accordance with NARA’s contingency planning policy.

_______________________ ________________________Jason Clingerman DateSystem Owner

1

1.0 IntroductionInformation systems are vital to NARA mission/business processes; therefore, it is critical that services provided by the DAS system are able to operate effectively without excessive interruption. This Information System Contingency Plan (ISCP) establishes comprehensive procedures to recover DAS quickly and effectively following a service disruption.

1.1 Background

This DAS ISCP establishes procedures to recover DAS following a disruption. The following recovery plan objectives have been established:

Maximize the effectiveness of contingency operations through an established plan that consists of the following phases:

o Activation and Notification phase to activate the plan and determine the extent of damage;o Recovery phase to restore DAS operations; ando Reconstitution phase to ensure that DAS is validated through testing and that normal operations

are resumed. Identify the activities, resources, and procedures to carry out DAS processing requirements during

prolonged interruptions to normal operations. Assign responsibilities to designated NARA personnel and provide guidance for recovering DAS during

prolonged periods of interruption to normal operations. Ensure coordination with other personnel responsible for NARA contingency planning strategies. Ensure

coordination with external points of contact and vendors associated with DAS and execution of this plan.

1.2 Scope

This ISCP has been developed for DAS, which is classified as a low impact system, in accordance with Federal Information Processing Standards (FIPS) 199 – Standards for Security Categorization of Federal Information and Information Systems. Procedures in this ISCP are for low impact systems and designed to recover DAS within 48 hours (2 business days). This plan does not address replacement or purchase of new equipment, short-term disruptions lasting less than 48 hours, or loss of data at the onsite facility or at the user-desktop levels. As DAS is a low-impact system, alternate data storage and alternate site processing are not required.

1.3 Assumptions

The following assumptions were used when developing this ISCP:

DAS has been established as a low-impact system, in accordance with FIPS 199. DAS is partially provided as a service by the Amazon Web Services (AWS) cloud service provider. Alternate processing sites and offsite storage are not required for this system. The DAS system is inoperable and cannot be recovered within 48 hours (2 business days). Key DAS personnel have been identified and trained in their emergency response and recovery roles; they

are available to activate the DAS Contingency Plan. Additional assumptions as appropriate.

2

The DAS ISCP does not apply to the following situations:

Overall recovery and continuity of mission/business operations. The Business Continuity Plan (BCP) and Continuity of Operations Plan (COOP) address continuity of mission/business operations.

Emergency evacuation of personnel. The Occupant Emergency Plan (OEP) addresses employee evacuation.

Any additional constraints and associated plans should be added to this list.

2.0 Concept of OperationsThe Concept of Operations section provides details about DAS, an overview of the three phases of the ISCP (Activation and Notification, Recovery, and Reconstitution), and a description of roles and responsibilities of NARA personnel during a contingency activation.

2.1 System Description

The DAS system provides archival descriptions associated with digitized archived materials, conversion of legacy finding aids, and the day-to-day description of work performed by NARA’s description archivists. The DAS system employs a three-tier architecture consisting of Presentation, Service, and Data tiers.

The Presentation Tier represents the desktops or laptops NARA staff use to access the DAS system. The Service tier hosts the set of services that implement the DAS system methods and expose data. The Data tier contains all data held and controlled by the DAS system.

Users’ Windows machines in the NARA environment contain the Presentation tier. Service and Data tiers are located in the public cloud provided by Amazon Web Services (AWS), and consist of Windows and Linux-based virtual machines. As such, interoperability and service orientation (a design paradigm for computer software in the form of services) are key requirements. The principle of service orientation provides the overall conceptual framework and serves as a basis for enabling technologies.

DAS is used for Archival description, the process of capturing, analyzing, controlling, exchanging, and providing access to information about the origin, content, and provenance of the records; their filing structure; their form and content; their relationship with other records; and, the ways in which they can be found and used so that the records may be served to the public.

Specific efforts and initiatives include: Archival description work; Authority work; Digital Public Library of America; Importing NARA partner descriptions and digitized records, and legacy NARA finding aids; and Creation of archival description sitemaps for Web search engines.

DAS manages new and updated descriptions and authorities to NARA’s National Archives Catalog system and provides prompt, easy, and secure access to NARA holdings anywhere, anytime. DAS includes standardized descriptions of both non-electronic and born-digital holdings, as well as links to other descriptive products.

Further detail is provided in the following appendices: Appendix F, Diagrams (System and Input/Output); Appendix G, Hardware & Software Inventory; Appendix H, Interconnections Table, Appendix J, Associated Plans and Procedures. The DAS BIA is stored within Xacta (see Appendix K, Business Impact Analysis).

3

2.2 Overview of Three Phases

This ISCP has been developed to recover and reconstitute the DAS using a three-phased approach. This approach ensures that system recovery and reconstitution efforts are performed in a methodical sequence to maximize the effectiveness of the recovery and reconstitution efforts and minimize system outage time due to errors and omissions.

The three system recovery phases are:

Activation and Notification Phase – Activation of the ISCP occurs after a disruption or outage that may reasonably extend beyond the RTO established for a system. The outage event may result in severe damage to the facility that houses the system, severe damage or loss of equipment, or other damage that typically results in long-term loss.

Once the ISCP is activated, system owners and users are notified of a possible long-term outage, and a thorough outage assessment is performed for the system. Information from the outage assessment is presented to system owners and may be used to modify recovery procedures specific to the cause of the outage.

Recovery Phase – The Recovery phase details the activities and procedures for recovery of the affected system. Activities and procedures are written at a level that an appropriately skilled technician can recover the system without intimate system knowledge. This phase includes notification and awareness escalation procedures for communication of recovery status to system owners and users.

Reconstitution –The Reconstitution phase defines the actions taken to test and validate system capability and functionality at the original or new permanent location. This phase consists of two major activities: validating successful reconstitution and deactivation of the plan.

During validation, the system is tested and validated as operational prior to returning operation to its normal state. Validation procedures may include functionality or regression testing, concurrent processing, and/or data validation. The system is declared recovered and operational by system owners upon successful completion of validation testing.

Deactivation includes activities to notify users of system operational status. This phase also addresses recovery effort documentation, activity log finalization, incorporation of lessons learned into plan updates, and readying resources for any future events.

2.3 Roles and Responsibilities

The ISCP establishes several roles for DAS recovery and reconstitution support. Persons or teams assigned ISCP roles have been trained to respond to a contingency event affecting DAS.

Roles and responsibilities are defined in the table below. Personnel assigned to these roles are identified in Appendix A, Personnel Contact List. Appendix B, Vendor Contact List, provides vendor contact information.

Contingency Plan Role

DAS Role Responsibilities

ISCP Director / ISCP Director (Alternate)

DAS System Owner

Overall management of the ISCP Confirming severity of a system disruption with the ISCP

Coordinator Formal activation of the ISCP

4

Contingency Plan Role

DAS Role Responsibilities

Notifying the ISCP Coordinator to begin formal assessment of the system disruption and develop recovery strategies

Notifying the ISCP Coordinator to assemble the ISCP Recovery Teams and begin system recovery

Overseeing annual testing, maintenance, and distribution of the plan

Contacting vendors, contractors or other external organizations to assist in the system recovery as necessary

Making initial assessment of system disruption (i.e., is it a minor system failure or a catastrophic event/major system failure)

For a minor system failure:o Assure that the incident is reported to NARA IT

Operations and logged in the trouble ticket system.o Assess the system disruptiono Estimate system recovery timeo Contact and instruct all necessary ISCP Recovery Team

members to recover the failing system component(s) For a catastrophic event/major system failure:

o Initiate full activation of the ISCPo Assess the system disruption and develop recovery

recommendations; providing thorough assessment of catastrophic events/major system failures

o Develop the damage assessment report and determine recovery and resumption strategies

o Contact all necessary ISCP Recovery Team Members and instruct them to assemble their teams to recover the failing system component(s)

Coordinating communications between the ISCP Recovery Teams in recovering the system

Complete an after action report upon resumption of normal operations

Ensure the annual testing, maintenance, and distribution of the plan

ISCP Coordinator / ISCP Team Member

All necessary technicians, administrators, and programmers from the major divisions

Assisting in all recovery and resumption activities for minor system failures, as necessary

Assisting in all recovery and resumption activities for catastrophic events/major system failures, as necessary

3.0 Activation and NotificationThe Activation and Notification Phase defines initial actions taken once a DAS disruption has been detected or appears to be imminent. This phase includes activities to notify recovery personnel, conduct an outage assessment, and activate the ISCP. At the completion of the Activation and Notification Phase, DAS ISCP staff will be prepared to perform recovery measures.

3.1 Activation Criteria and Procedure

The DAS ISCP may be activated if one or more of the following criteria are met:

5

The cloud service provider indicates an outage that will exceed the RTO of 48 hours The type of outage indicates DAS will be down for more than 48 hours (2 business days); The facility housing DAS is damaged and may not be available within 48 hours; and Other criteria, as appropriate.

The following persons or roles may activate the ISCP if one or more of these criteria are met:

ISCP Director / ISCP Director (Alternate)

Details on the responsibilities for the ISCP Director / ISCP Director (Alternate) can be found in Section 2.3.

3.2 Notification

The first step upon activation of the DAS ISCP is notification of appropriate mission/business and system support personnel. Contact information for appropriate POCs is included in Appendix A, Personnel Contact List and Appendix B, Vendor Contact List.

Notification of outage incidents for DAS that require activation of the ISCP will be performed through phone or email. The following information should be relayed to individuals during the notification phase:

Nature of the emergency that has occurred or is impending; Loss of life or injuries; Any known damage estimates; Response and recovery details; Where and when to convene for briefing or further response instructions; Instructions to prepare for relocation for estimated time period (if applicable); Instructions to complete notifications (if applicable).

The notification sequences provided below are divided into two categories, minor system failures and major system failures. The ISCP Director will classify the severity of the system failure once it has been reported to the DAS Support Contractor (DSA Inc.) and the NARA/DSA Help Desk and will determine whether to activate the contingency plan assessment procedures. It is important to note that the ISCP Director may be contacted directly in the event of a system failure, especially if the person reporting the incident is external to the department (AWS, facilities management personnel, building security, etc.). Depending on the severity of the event, one of the following notification sequences will be used. It is important to note that the ISCP will not be activated in the event of a minor system failure. Nevertheless, notification procedures for minor system failures have been provided to standardize recovery operations.

Minor System Failure Notification ProceduresIn the event of a Minor System Failure, the following notification procedures will be followed:

The first person to detect a system disruption notifies the ISCP Director. The ISCP Director determines that a minor system failure has occurred and ISCP activation is not

necessary. The ISCP Director will notify system stakeholders of the minor system failure. The ISCP Director notifies all necessary ISCP Recovery Team Leaders and directs them to follow

Standard Operating Procedures (SOPs) in the recovery of all failing DAS components. The ISCP Director will notify system stakeholders when the issue is resolved.

Major System Failure Notification ProceduresIn the event of a Major System Failure, the following notification procedures will be followed:

The first person to detect a system disruption notifies the ISCP Director. The ISCP Director evaluates the situation and activates the plan if it is anticipated that the system will not

6

be recovered within 72 hours (3 business days). The ISCP Director will notify all system stakeholders of the major system failure. Upon activation of the CP, the ISCP Director develops a damage assessment report. Upon activation of the CP, the ISCP Director will also contact the NARA Helpdesk to aid in the

development of the damage assessment report. The ISCP Director contacts the appropriate team members to assist in the damage assessment procedures. The ISCP Director determines the extent of the system damage and the estimated recovery time and

confirms recovery strategies. The ISCP Director notifies vendor or contractor POC(s) if additional external assistance is necessary. The ISCP Director briefs the appropriate individuals/managers to assemble their team members for

recovery activities.

The ISCP Director will notify all system stakeholders when the issue is resolved.

3.3 Outage Assessment

The cloud service provider is responsible for the outage assessment if it is within the scope of their services. That assessment will include the extent of the disruption and expected recovery time.

If the outage is outside the scope of the cloud service provider, a thorough outage assessment is necessary to determine the extent of the disruption, any damage, and expected recovery time. This outage assessment is conducted by the technical team. Assessment results are provided to the ISCP Coordinator to assist in the coordination of the recovery of DAS.

Once personnel safety has been assured, the ISCP Director and appropriate team members should seek to determine the following information:

Cause of the emergency or disruption; Potential for additional disruptions or damage; Areas affected by the emergency; Status of the physical infrastructure (e.g., structural integrity of the processing rooms, condition of

electric power, telecommunications, and heating, ventilation, and air conditioning [HVAC]); Inventory and functional status of the DAS components (e.g., fully functional, partially functional, or

nonfunctional); Type of damage to the DAS components (e.g., water damage, fire and heat, physical impact, and

electrical surge); DAS components to be replaced; Estimated time to restore normal services.

Assessment results will be provided to the ISCP Director.

4.0 RecoveryThe Recovery Phase provides formal recovery operations that begin after the ISCP has been activated, outage assessments have been completed (if possible), personnel have been notified, and appropriate teams have been mobilized. Recovery Phase activities focus on implementing recovery strategies to restore system capabilities, repair damage, and resume operational capabilities at the original or an alternate location. At the completion of the Recovery Phase, DAS will be functional and capable of performing the functions identified in Section 2.1 of this plan.

7

4.1 Sequence of Recovery Activities

The following activities occur during recovery of DAS:

Identify recovery location (if not at original location); Identify required resources to perform recovery procedures; Retrieve backup and system installation media; Recover hardware and operating system (if required); and Recover system from backup and system installation media.

4.2 Recovery Procedures

The following procedures are provided for recovery of DAS at the original location. Recovery procedures should be executed in the sequence presented to maintain an efficient recovery effort.

DAS is an n-tier application wherein the UI is a Windows desktop app, the application tiers (messaging and Service Oriented Architecture (SOA)) and the database tiers are in AWS. Regular snapshots of the application servers are maintained. Hence, if one of the application servers were to fail, a new server can be provisioned in minutes using such a snapshot. Additionally, most of the application servers are behind a load balancer in an auto scaling group so as to not only provide load sharing, but also continuity of operation while the failed server is automatically replaced using a pre-defined snapshot. In the database tier, a hot standby is maintained such that in case of a database crash, it is easy to promote the standby to primary and switch the data sources in the application tier to minimize impact on DAS users. Once DAS is operational again, the latest nightly full backup of the Oracle database is used to restore the failed primary database and convert it into the new standby database.

4.3 Recovery Escalation Notices/Awareness

While the recovery effort is underway, hourly status notification will be made to the ISCP Director/ISCP Coordinator by the appropriate support vendor (application and/or infrastructure).

5.0 ReconstitutionReconstitution is the process by which recovery activities are completed and normal system operations are resumed. If the original facility is unrecoverable, the activities in this phase can also be applied to preparing a new permanent location to support system processing requirements. A determination must be made on whether the system has undergone significant change and will require reassessment and reauthorization. Reconstitution consists of two major activities: validating successful reconstitution and deactivation of the plan.

5.1 Validation Data Testing

Validation data testing is the process of testing and validating data to ensure that data files or databases have been recovered completely at the permanent location. Detailed validation test procedures are provided in Appendix E, System Validation Test Plan.

5.2 Validation Functionality Testing

Validation functionality testing is the process of verifying that DAS functionality has been tested, and the system is ready to return to normal operations. Detailed functionality test procedures are provided in Appendix E, System Validation Test Plan.

5.3 Recovery Declaration

Upon successfully completing testing and validation, the ISCP Director/ISCP Coordinator will formally declare

8

recovery efforts complete, and that DAS is in normal operations. DAS business and technical POCs will be notified of the declaration by the ISCP Coordinator.

5.4 Notifications (users)

Upon return to normal system operations, DAS users will be notified by the ISCP Director/ISCP Coordinator using the most applicable media (e-mail, broadcast message, phone calls, etc.).

5.5 Cleanup

Cleanup is the process of cleaning up or dismantling any temporary recovery locations, restocking supplies used, returning manuals or other documentation to their original locations, and readying the system for a possible future contingency event.

Materials, plans, and equipment used during the recovery and testing must be returned to storage or their proper location. All sensitive materials must be destroyed or properly returned to safe storage, as appropriate. Any personnel temporarily assisting other office locations during the disruption should be instructed by their respective team leaders to conclude their assistance and report to their primary sites and duties.

5.6 Data Backup

As soon as reasonable following recovery, the system should be fully backed up and a new copy of the current operational system stored for future recovery efforts. This full backup is then kept with other system backups. The DAS Server Backup Schedule is provided below:

DAS Server Backup Schedule

Server Name Server Type Backup Schedule

Primary Database Server Database Incremental Backups; Every Weekday

Primary Database Server Database Full Backups: Every Week

Snapshots of the server whenever there is a new deployment or every two weeks System Snapshots Whenever there is a new system

deployment.

5.7 Event Documentation

It is important that all recovery events be well-documented, including actions taken and problems encountered during the recovery and reconstitution effort, and lessons learned for inclusion and update to this ISCP. It is the responsibility of each ISCP team or person to document their actions during the recovery and reconstitution effort, and to provide that documentation to the ISCP Coordinator.

Types of documentation that should be generated and collected after a contingency plan activation include:● Activity logs (including recovery steps performed and by whom, the time the steps were initiated and

completed, and any problems or concerns encountered while executing activities);● Functionality and data testing results;● Lessons learned documentation; and,● After Action Report (including identification of any new components including all information applicable

to the Configuration Management (CM) documentation.

9

5.8 Deactivation

Once all activities have been completed and documentation has been updated, the ISCP Director/ISCP Coordinator will formally deactivate the ISCP recovery and reconstitution effort. Notification of this declaration will be provided to NARA Helpdesk, all businesses and technical POCs.

The following procedures will be followed to deactivate the ISCP for DAS:

1. Verify that the application is functioning correctly.2. Inform vested parties that the application has been restored and is functioning properly.3. Log details of the event and problems encountered with the ISCP.4. Incorporate problem solutions into later versions of the ISCP.

10

APPENDIX A: PERSONNEL CONTACT LISTDAS ISCP Key Personnel

Key PersonnelKey Contact InformationISCP Director Work 301-837-3022Jason Clingerman System Owner Home8601 Adelphi Rd. CellularCollege Park, MD 20740 Email jason.clingerman@nara.gov

ISCP Director – Alternate Work 301-837-3024Richard Steinbacher Home

CellularEmail richard.steinbacher@nara.gov

ISCP Coordinator Work 301-837-3022Jason Clingerman System Owner Home

CellularEmail jason.clingerman@nara.gov

ISCP Coordinator – Alternate Work 301-837-3024Richard Steinbacher Home

CellularEmail richard.steinbacher@nara.gov

ICSP Team – Team Members Work 301-837-3161Adil Latiwala – Technical Point of Contact Home

Cellular 240-593-5831Email adil.latiwala@nara.gov

Anton Davis - ISSO Work 301-837-0430HomeCellular 301-755-7026Email william.davis@nara.gov

Urmi Majumder – System Administrator WorkHomeCellularEmail urmi.majumder@dsainc.com

NARA Helpdesk Work 703-872-7755

Email ITsupport@nara.gov

11

APPENDIX B: VENDOR CONTACT LIST

Vendor Contact List

Key Personnel

Vendor Component/Service Contact Information

Oracle Database Phone: 1-800-223-1711Red Hat Web Servers Phone: 1-800-872-4786Apache Web Servers Phone: 1-800-872-4786Microsoft Reporting Server Phone: 1-800-642-7676DSA Service Phone: 1-703-748-7001Amazon Web Services (AWS) Cloud Service Provider Phone: 1-866-216-1072InfoReliance Cloud Service Provider Phone: 1-844-458-5433

12

APPENDIX C: DETAILED RECOVERY PROCEDURESDAS is an n-tier application wherein the UI is a Windows desktop app, the application tiers (messaging and SOA) and the database tiers are in AWS. Regular snapshots of the application servers are maintained. Hence, if one of the application servers were to fail, a new server can be provisioned in minutes using such a snapshot. Additionally, most of the application servers are behind a load balancer in an auto scaling group so as to not only provide load sharing but also continuity of operation while the failed server is automatically replaced using a pre-defined snapshot. In the database tier, a hot standby is maintained such that in case of a database crash, it is easy to promote the standby to primary and switch the data sources in the application tier and minimize impact on DAS users. Once DAS is operational again, the latest nightly full backup of the Oracle database is used to restore the failed primary database and convert it into the new standby database.

13

APPENDIX D: ALTERNATE PROCESSING PROCEDURESIf the DAS Data Entry system is unavailable, the ISCP Director/DAS Technical Liaison shall inform staff via:

Email ICN DAS Points of Contact (POCs)

The email messages shall inform staff members that they may use the following methods to capture information to be entered later into the DAS Data Entry system when it is again available.

To determine what fields are mandatory, access the Lifecycle Data Requirements Guide (LCDRG) online at http://www.nara-at-work.gov/archives_and_records_mgmt/archives_and_activities/accessioning_processing_description/lifecycle/mandatoryelements.html

To determine what other fields are mandatory for a particular office, access http://www.nara-at-work.gov/archives_and_records_mgmt/archives_and_activities/accessioning_processing_description/lifecycle/mandatoryelements.html

For all other fields, refer to the full LCDRG at http://www.nara-at-work.gov/archives_and_records_mgmt/archives_and_activities/accessioning_processing_description/lifecycle/index.html

To ensure the data they are capturing is correctly formatted according to the standards; refer to each element entry in the LCDRG.

For fields that are controlled by authority lists, refer to the list that is available through the LCDRG. For fields that are controlled by authority files, format the name and/or heading as best as possible. For

Organization Names and Person Names, search the authority files online via DAS or NAC. For all other headings, enter the term as it is known. After DAS Data Entry is available, it will be necessary to search and select the appropriate name or heading from the authority files.

Using the above information, staff may enter the descriptive information in a spreadsheet with field names as the header and data values beneath. Once the DAS Data Entry system is available, they may cut and paste the information into the DAS system, type it directly into the system and/or select the appropriate values from the authority lists or files, or have Digital Public Access Branch staff convert the spreadsheets into XML for bulk import.

Alternatively, staff may generate their own XML data (following the DAS XML schema) to be imported by Digital Public Access Branch staff after the system becomes available.

If the network is down, DAS users may refer to a printed LCDRG (if available) and handwrite or capture their descriptive information. The printed version, however, does not include any of the authority lists.

14

APPENDIX E: SYSTEM VALIDATION TEST PLANThe following procedures will be used to determine that the data is complete and current to the last available backup:

Once database is restored, we will validate if there are any corrupt data blocks and that all data files have been physically restored to the correct location using RMAN.

Procedure Expected Results Performed by

To use VALIDATE to check database files and backups. This will tell if there is any corrupt block in the RMAN back up set.

Start RMAN and connect to a target database. Execute the VALIDATE command with the

desired options. For example, to validate all datafiles and

control files (and the server parameter file if one is in use), execute the following command at the RMAN prompt:

RMAN> VALIDATE DATABASE;

Check the # of datafiles , their location and status from database control file and dictionary:

a. select name from v$datafile;

b. select file_name, status, ONLINE_STATUS from dba_data_files;

To validate that all datafiles have been physically restored to the correct location:

Login to the server as grid userThe list command should return the same number of rows as returned from v$datafiles (specified in database control file)

DSA

Validation Functionality Test:

Functionality Test Responsible PartyCreate/Edit/Modify Data DSAWorkflow DSAAPI DSAExport DSAIngest DSAAuthority and Description Searches DSA

15

APPENDIX F: DIAGRAMS (SYSTEM AND INPUT/OUTPUT)Figure 1: DAS System Architecture

16

APPENDIX G: HARDWARE AND SOFTWARE INVENTORYSystem inventory is found in Xacta and attached below:

17

APPENDIX H: INTERCONNECTIONS TABLEThe ERA 2.0 system connects to DAS via an application programming interface (API). The DAS system generates weekly data export for the records created, modified, deleted from previous week in XML format and provides to NAC for ingestions. As required, the DAS system can also provide full data set in XML format.

18

APPENDIX I: TEST AND MAINTENANCE SCHEDULEStep Date Due by Responsible Party Date Scheduled Date Held

Identify tabletop facilitator. March 2020 ISCP Coordinator March 2020 March 2020Develop tabletop test plan. March 2020 Tabletop Facilitator March 2020 March 2020Invite participants. March 2020 Tabletop Facilitator March 2020 March 2020Conduct tabletop test. March 2020 Facilitator, ISCP

Coordinator, POCsMarch 25, 2020 March 25, 2020

Finalize after action report and lessons learned.

April 2020 ISCP Coordinator April 2020 April 2020

Update ISCP based on lessons learned.

April 2020 ISCP Coordinator April 2020 April 2020

Approve and distribute updated version of ISCP.

April 2020 ISCP Director, ISCP Coordinator

April 2020 April 2020

19

APPENDIX J: ASSOCIATED PLANS AND PROCEDURESArtifacts related to plans and procedures such FIPS 199, BIA, and System Security Plan (SSP) are maintained as separate documents and can be found in Xacta.

20

APPENDIX K: BUSINESS IMPACT ANALYSISBIA is found in Xacta and attached below:

21

APPENDIX L: DOCUMENT CHANGE PAGEModifications made to this plan are as follows:

Document Version

Description of contents / revision Editor Change Date

1.0 ISCP developed based on new template NARA 05/10/2017

2.0 Review and update of ISCP ISSO – John Nelson 05/14/2019

3.0 FY20 Annual update. RTO in sections 1.2, 1.3, and 3.1 updated to match the FY20 BIA. Notifications updated to include NARA Helpdesk. Appendix A Contact List updated. Inventory and BIA updated with FY20 information. Test and maintenance dates updated to reflect the FY20 tabletop exercise.

ISSO – Anton Davis 04/15/2020

22