SAP

Security Categorization: High

Omega Research

Information System Contingency Plan (ISCP)

Version 1

[12/14/14]

Prepared by Tim Haney

[Omega Research] [3456 Winchester Blvd] [San Diego, Ca, 94511]

1

Table of Contents

Plan Approval…………………………………………………………………………..…….3

1. Introduction………………………………………………………………………......3Background…………………………………………………………………………..3Scope………………………………………………………………………….……….4

Assumptions………………………………………………………………………….4

2. Concept of Operations……………………………………………………………..5System Description…………………………………………………………………5Overview of Three Phases…………………………………………………………6Roles and Responsibilities………………………………………………………..8

3. Activation and Notification………………………………………………………..8Activation Criteria and Procedure……………………………………………….8Notification…………………………………………………………………………..8Outage Assessment………………………………………………………………..10

4. Recovery……………………………………………………………………………..11Sequence of Recovery Activities………………………………………………..11Recovery Procedures……………………………………………………………..11Escalation Notices/Awareness…………………………………………………..12

5. Reconstitution……………………………………………………………………….13Concurrent Processing…………………………………………………………….13Validation Data Testing…………………………………………………………….14Validation Functionality Testing………………………………………………….14Recovery Declaration………………………………………………………………14Notifications (Users)………………………………………………………………..14Cleanup……………………………………………………………………………….14Offsite Data Storage………………………………………………………………..14Data Backup…………………………………………………………………………15Even Documentation………………………………………………………………15Deactivation…………………………………………………………………………15

Appendices………………………………………………………………………….16

References…………………………………………………………………………..23

2

Plan Approval

As the designated authority for SAP 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 the Omega Research , 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 SAP System will be tested at least annually. This plan will be tested on 1/15/15; the test, training, and exercise (TT&E) material associated with this test can be found TT&E results appendix. This document will be modified as changes occur and will remain under version control, in accordance with Omega Corporation contingency planning policy.

Tiffany Sabers Chief Information Officer Date 11/24/14

1. Introduction

Information systems are vital to Omega Research business processes; therefore, it is critical that services provided by SAP System are able to operate effectively without excessive interruption. This Information System Contingency Plan (ISCP) establishes comprehensive procedures to recover SAP System quickly and effectively following a service disruption.

1.1 Background

This SAP System Information System (IS) Contingency Plan (CP) establishes procedures to recover SAP System 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:

Activation and Notification phase to activate the plan and determine the extent of damage;

Recovery phase to restore SAP System operations; and

Reconstitution phase to ensure that SAP is validated through testing and that normal operations are resumed.

Identify the activities, resources, and procedures to carry out SAP System processing requirements during prolonged interruptions to normal operations.

Assign responsibilities to designated Omega Research personnel and provide guidance for recovering SAP System during prolonged periods of interruption to normal operations.

Ensure coordination with other personnel responsible for Omega Research contingency planning strategies. Ensure coordination with external points of contact and vendors associated with SAP System and execution of this plan.

3

1.2 Scope

This ISCP has been developed for SAP System which is classified as a High-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 High- Impact systems and designed to recover SAP System within 24 hours. This plan does not address replacement or purchase of new equipment, short-term disruptions lasting less than 24 hours or loss of data at the onsite facility or at the user-desktop levels.

1.3 Assumptions

The following assumptions were used when developing this ISCP:SAP System has been established as a High-Impact System, in accordance with FIPS 199.

Alternate processing sites and offsite storage are required and have been established for this system.

Current backups of the system software and data are intact and available at the offsite storage facility in Reston, VA.

Alternate facilities have been established at Philadelphia, PA and are available if needed for relocation of SAP System.

The SAP is inoperable at the Omega Research computer center and cannot be recovered within 24 hours.

Key SAP System personnel have been identified and trained in their emergency response and recovery roles; they are available to activate the SAP System Contingency Plan.

The SAP Contingency Plan does not apply to the following situations:

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

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

4

CONTINGENCY PLANNING GUIDE FOR FEDERAL INFORMATION SYSTEMS (DRAFT)

2. Concept of Operations

The Concept of Operations section provides details about SAP System, an overview of the three phases of the ISCP (Activation and Notification, Recovery, and Reconstitution), and a description of roles and responsibilities of Omega Research’s personnel during a contingency activation.

2.1 System Description

5

Reston office: SMTP Mail Gateway, File/ Print Server, Exchange 2000 server, Web Server, DNS, RAS, PBX, workstations and printers.

San Diego office: SMTP Mail Gateway, File/Print Server, Exchange 2000 mail server, DNS, RAS, PBX, workstations, and Printers.

Salem office: File/Print server, VPN Gateway, workstations, and Printers.

Kansas City office: File/print Server, Exchange Server, VPN Gateway, workstations, and Printers.

Reston office description: Perimeter protection provided by screening router (ACLs). Remote access is provided to employees while at home or on travel through PPTP VPN, and dial-up RAS offered by a Microsoft Windows N.T. Server. All servers in the Reston office have been centrally located to a data center. The data center supports a 5-keypunch combination lock that is required to have access to the room and is controlled with HVAC for temperature with isolated services and is not on a raised floor to control static electricity. Each server and network equipment supports their own mini-UPS.

Email uses Microsoft Exchange Server 2000 mail server running on a Windows 2000 Server with SMTP mail gateway. Omegaresearch.com is the domain name with a DNS server used for name resolution for public internet access. Web hosting services are provided by Windows 2000 Server running Internet Information Services (IIS). X.500 directory services are available through active directory. Server and client OS (operating system) environments have not been patched. All printers are networked. The IT department manages more than 170 workstations and 6 servers. Client machines consist of Microsoft Windows 95, 98, NT workstation 4.0, 2000, and XP. Mac operating systems (OS) including OS8 and OS-X, and Panther. Productivity applications have not been standardized. Some users enjoy Corel OfficeSuite while others appreciate Microsoft Office.

San Diego office description: It is essentially a mirror of Reston architecture. The only differences are that it does not have a web server or support VPN or RAS connections. There are fewer employees here, and only one IT engineer for the entire office. There are less than 50 client machines with similar configurations as the main office. All servers have been located in an extra office and do not have HVAC for a controlled environment for humidity, temperature, or static. There is no access control in place and there are no redundant power supplies.

Salem office description: Contains only 30 workstations, configured in much the same way as the rest of the company. It supports a single combined shared file and print server hosted on a Microsoft Windows NT 4.0 Server. Mail services are obtained through the San Diego office, using mailboxes setup on the San Diego Exchange Server. No publicly available networked resources. Remote access is allowed through VPN client to gateway connectivity. It has one IT engineer to manage its IT resources. All servers have been located in a spare room in San Diego. The servers have no access restriction, with no HVAC to control humidity, temperature, and static. There are no redundant power supplies.

Kansas City office description: It is a similar size to the Salem office with the exception that Kansas City runs a Microsoft Exchange 2000 server for mail services. It has a local system administrator for support. All servers have been located in a spare office onsite. There is no HVAC or access restrictions. The office is not controlled for temperature, humidity, or static. There are no redundant power supplies.

2.2 Overview of Three Phases

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

6

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 Phase – The Reconstitution phase defines the actions taken to test and validate system capability and functionality. This phase consists of two major activities: validating successful recovery 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 recovery events.

7

2.3 Roles and Responsibilities

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

The following are roles and responsibility of each ISCP Support Team:

1. ISCP Director (Bill Hermann, Executive CEO) and alternate (John Sampolous, CFO) have overall management responsibility for the plan. They are included in a Management Recovery Team.

2. ISCP Coordinator (Tim Haney, IT Manager) and alternate (Linda Okonieski, COO) initiate any needed escalations or awareness communications, oversee recovery effort, and coordinate with other recovery teams. They are included in the Recovery Team.

3. Server Recovery Team (Tyler Amdahi, Director of I.T. Operations) and (Rachid Chad, Dir. Of IT) are responsible for restoration of Web Email, desktop support, email system, and other technical support.

4. Database Recovery Team (Tiffany Sabers, CIO, Information Technology) and (Sandy Ales, Director of Sales and Marketing) are responsible for restoration of the SAP system Database.

5. Network Recovery Team (Jackson Davis, Director of Accounting) and (Fionna O’Connor, Director of Audit and Compliance) are responsible for restoration of the WAN/LAN telecommunications.

3. Activation and NotificationThe Activation and Notification Phase defines initial actions taken once a SAP System 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, SAP System ISCP staff will be prepared to perform recovery measures to restore system functions.

3.1 Activation Criteria and Procedure

The SAP System ISCP may be activated if one or more of the following criteria are met:1.The type of outage indicates SAP System will be down for more than 24 hours2.The facility housing SAP System is damaged and may not be available within 24 hours

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

1.CIO (Chief Information Officer)2.Alternate CIO

Tiffany Sabers, 858-934-1245Tim Haney, 858-234-0943

3.2 Notification

The first step upon activation of the SAP System ISCP is notification of appropriate business and system support personnel. Contact information for appropriate POCs is included in the contact list Appendix A and B.

For SAP System, the following method and procedure for notifications are used:

8

1. The Recovery Team Leads, Vendors and the ISCP Director will be contacted by the ISCP Coordinator or alternate for initial notification. The Team Leads will contact their members as shown in the notification call tree diagram.

2. When an outage occurs, Business Owners and Stakeholders should also be notified by the ISCP Coordinator.

3. Use primary email and cell number for outage notification. If these do not work, use the satellite phone.

4. See the Notification Checklist.

Notification Call Tree

Notification Check list

Number Task Responsibility Date/Time Status (check if completed)

9

1. Notify ISCP Team with call lists

Refer to Notification Call Tree

2. Recovery team meets to discuss strategy

ISCP Coordinator

3. Alert Vendor and Recovery Site

ISCP Coordinator

4. ISCP Coordinator will be advised by Recovery Team to notify Senior Management

Recovery Team Lead

5. Activate Contingency Plan

CIO

6. Declare a disaster and activate plan

CIO

7. Notify Hotsite and Business Owners/Stakeholders

ISCP Coordinator

3.3 Outage Assessment

Following notification, 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 Disaster

10

Recovery Team Lead . Assessment results are provided to the ISCP Coordinator to assist in the coordination of the recovery of SAP System.

Once the outages occurs, the following procedures should be followed:

1. Determine cause of the outage or disruption;

2. Assess the potential for additional disruptions or damage;

3. Determine the status of physical infrastructure (e.g., structural integrity of computer room, condition of electric power, telecommunications, and heating, ventilation and air-conditioning [HVAC]);

4. Inventory and functional status of SAP system and other related applications like email and Web services.

5. Determine the type of damage to system equipment or data (e.g., water, fire and heat, physical impact, electrical surge) or other items which may be critical.

6. Determine items to be replaced (e.g., hardware, software, firmware, supporting materials); and

7. Determine estimated time to restore normal services.

4. Recovery

The 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 new permanent location. At the completion of the Recovery Phase, SAP System will be functional and capable of performing the functions identified in the plan.

1. Temporary manual processing like using Excel spreadsheets.

2. Recovery and operation at an alternative site at Philadelphia, PA.

3. Systems with high criticality will be recovered like: Email Server, Web Server, VPN Gateway, DNS, RAS, and client machines.

4.1 Sequence of Recovery Activities

The following activities occur during recovery of SAP System :

1.The recovery location is in Philadelphia, PA at SunGard.

2.Recovery services for the SAP system will be for a server environment. The critical system resources to be recovered first are Email Server, then Web Server, then DNS, then RAS, then client machines, and last File/Print Server and PBX.

3.Retrieve backup and SAP system installation media;

4.Recover Servers and Windows N.T. Server.

5.Recover SAP system from backup and system installation media at Reston, Va. Or from Philadelphia, where are backup tapes are sent.

4.2 Recovery Procedures

11

The following procedures are provided for recovery of SAP system at the established location in Philadelphia, PA . Recovery procedures are outlined per team and should be executed in the sequence presented to maintain an efficient recovery effort.

To facilitate Recovery Phase operations, the ISCP should provide detailed procedures to restore the information system or components to a known state.

Procedures should be assigned to the ISCP recovery teams and typically address the following actions:

1. Obtaining authorization to access damaged facilities and/or geographic area;

2. Notifying internal and external business partners associated with the SAP system;

3. Obtaining necessary office supplies and work space at Philadelphia.

4. Obtaining and installing Email Server, Web Server, DNS, RAS, and client machines.

5. Obtaining and loading backup media from Reston, VA.

6. Restoring critical SAP and Windows Server applications.

7. Restoring SAP system data to a known state;

8. Testing SAP system functionality including security controls;

9. Connecting SAP system to network or other external systems; and

10. Operating alternate equipment at SunGard in Philadelphia, PA successfully.

4.3 Escalation Notices/Awareness

12

Disaster recovery handling, as described in this document, starts with the escalation of an incident, which is seriously disrupting operations, to a disaster.

It is important to identify the type of error causing the disruption as early as possible, since the required recovery phases and applicable activities mainly depend on the error type.

When a disaster is declared, the following main phases of recovery may be applied in this order:

A. Activate the alternate site with SunGard in Philadelphia to stay in business. This can be a technical switchover to a standby system, or the activation of alternate business processing using workarounds or emergency plans.

Which options are possible or applicable depends on the solutions in place and the actual type of error. Activating a workaround will be easier and faster, if the workaround is already documented in a recovery plan.

B. Prepare SAP systems for the recovery.

C. If the SAP system or component is down, SAP system recovery or technical recovery, as a first step, has to reestablish technical availability of the SAP system by fixing any technical error causing the disruption. This can be done, for example, by exchanging some defect hardware component, by activating a standby system or by restoring a database from a backup.

D. If all components are up (or were recovered in the previous step), logical errors inside each system have to be removed to restore integrity of each system in itself. This requires in-depth application knowledge and is a prerequisite for the next step.

E. If data consistency between systems of the environment was affected, this again requires in-depth application knowledge and time to fix it.

F. If data was lost and could not be recovered so far, the next effort should aim at reentering such data into the systems.

G. Having finished all recovery phases, the systems and business functionality should be checked as a prerequisite for resuming regular operations.

5. Reconstitution

Reconstitution is the process by which a recovered system is tested to validate system capability and functionality. During Reconstitution, 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. This phase consists of two major activities – validating successful recovery and deactivation of the plan.

5.1 Concurrent Processing

13

SAP Systems should be fully tested which are interlinked before allowing user to have access to the system to ensure reliability.

5.2 Validation Data Testing

Validation data testing is the process of testing and validating recovered data to ensure that data files or databases have been recovered completely. The following procedures will be used to determine that the recovered data is complete and current to the last available backup:

See Appendix E and J.

5.3 Validation Functionality TestingValidation functionality testing is the process of verifying that recovered SAP functionality has been tested, and the system is ready to return to normal operations.

See Appendix E and J.

At the successful completion of the validation testing, ISCP personnel will be prepared to declare that reconstitution efforts are complete and that the system is operating normally. This declaration may be made in a recovery/reconstitution log or other documentation of reconstitution activities. The ISCP Coordinator, in coordination with the CIO, ISSO, SAISO and with the concurrence of the Authorizing Official, must determine if the system has undergone significant change and will require reassessment and reauthorization. The utilization of a continuous monitoring strategy/program can guide the scope of the reauthorization to focus on those environment/facility controls and any other controls which would be impacted by the reconstitution efforts.

5.4 Recovery Declaration

Upon successfully completing testing and validation, the CIO will formally declare recovery efforts complete, and that SAP System is in normal operations. SAP System business and technical POCs will be notified of the declaration by the ISCP Coordinator.

5.5 Notifications (users)

Upon return to normal system operations, SAP System users will be notified by ISCP Coordinator using pre-planned emails, cell phones, or satellite phones.

5.6 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.

Return all manuals and Backup Media back to Reston, VA.

5.7 Offsite Data Storage

14

It is important that all backup and installation media used during recovery be returned to the offsite data storage location. The following procedures should be followed to return backup and installation media to its offsite data storage location.

See Appendix F.

5.8 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 procedures for conducting a full system backup are:

See Appendix F.

Backups in Reston, VA. Backup tapes sent to Philadelphia, PA.

5.9 Event Documentation

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

An after-action report with lessons learned should be documented and included for updating ISCP.

Each Recovery Team (Network, Database, and Server) keep activity logs detailing recovery steps and issues. The results from Functionality and data testing:

1. Development

2. Collection

3. Approval

4. Maintenance

-Testing as an audit tool.

-Testing as a benchmarking.

-Testing as rehearsal.

5.10 Deactivation

Once all activities have been completed and documentation has been updated, the CIO will formally deactivate the ISCP recovery effort. Notification of this declaration will be provided to all business and technical POCs.

15

SUGGESTED APPENDICES

APPENDIX A PERSONNEL CONTACT LISTSAP ISCP Key Personnel

Key Personnel Contact InformationISCP Director Work 703-123-4567

Bill Hermann, CEO Home 703-567-43211234 Smith Street Cellular 703-954-5432Reston, Virginia, 20190 Email Bhermann@Omega.comISCP Director – Alternate Work 703-765-5430

John Sampolous, CFO Home 703-098-93211234 Moorpark Ave. Cellular 703-654-3456Reston, Virginia, 20191 Email Jsampolous@Omega.com

ISCP Coordinator Work 619-123-4567Tim Haney IT Manager Home 858-234-43211234 Fenley Ave. Cellular 619-453-4321San Diego, Ca , Email Thaney@Omega.com

ISCP Coordinator – Alternate Work 503-876-6543Linda Okonieski, COO Home 503-986-54213456 Winchester Blvd Cellular 503-346-8751Salem, Oregon, 97303 Email Lokonieski@Omega.com

Recovery Team – Team Lead Work 816-613-8157Jackson Davis, Dir of Accounting Home 816-025-96414567 Stevens Creek Blvd Cellular 816-753-0921Kansas City, Missouri, 64101 Email Jdavis@Omega.com

Recovery Team – Team Member Work 816-036-6426Fionna O’Connor, Dir. Of Audit Home 816-841-76319843 Andrea Drive Cellular 816-654-8732Kansas City, Missouri, 64101 Email FOconnor@Omega.com

APPENDIX B VENDOR CONTACT LISTVendor Services Address Phone ContactsIBM Tape Library

TSM Server522 South Rd.Poughkeepsie, NY, 12601

214-451-7747 Steve Barretta

SunGard Recovery services for server environment

401 N Broad St. Philadelphia, PA

877-456-3966215-351-1300

-Don Meltin (test Coordinator)-Jack Fabrinni (Acct. Rep)-Lincoln Balducci (Resource Coord.)

AT&T Leased Line 3495 Winchester Blvd, Reston, VA

877-345-5432 Andy Cates

16

APPENDIX C DETAILED RECOVERY PROCEDURES

-Restore the operating system disk with Automated System Recovery (ASR).

-Boot Windows Server 2003 from the installation DVD and press the F2 key.

-For more information, see the Windows ASR documentation.

-Restore non-operating system disks with NTBackup.

-For more information, see the F1 help in NTBackup.

-Restore the database.

APPENDIX D ALTERNATE PROCESSING PROCEDURES

An alternate processing procedure would be to use Excel spreadsheets manually until systems are back online.

APPENDIX E SYSTEM VALIDATION TEST PLAN

Once the system has been recovered, the following steps will be performed to validate system data and functionality:

Procedure Expected Results Actual Results Successful? Performed by

At the Command Prompt, type in sysname

System Log-in Screen appears

Log in as usertestuser, using password testpass

Initial Screen with Main Menu shows

From Menu - select 5- Generate Report

Report Generation Screen shows

- Select Current Date Report- Select Weekly- Select To Screen

Report is generated on screen with last successful transaction included

- Select Close Report Generation Screen Shows

- Select Return to Main Menu

Initial Screen with Main Menu shows

- Select Log-Off Log-in Screen appears

17

APPENDIX F ALTERNATE STORAGE, SITE, AND TELECOMMUNICATIONS

Alternate Storage:

The hot-site will be located in Philadelphia, PA. It is located 154 miles from the primary facility. The alternate storage facility is a third party storage provider SunGard. Points of contact is Jack Fabrianni at 877-456-3966. Those authorized to retrieve media are Don Meltin and Lincoln Balducci at 215-351-1300. The facility will be protected with a badge and password protected lock inside and outside the building. In the case of an emergency like an earthquake, the facility may be unavailable to people outside of the country. The facility has a backup generator in case it loses power. The facility has some satellite phones available in case phone lines are down. There are servers, EDW (enterprise data warehouse), Hyperion Express, UFS (Unix file system), Brio SQR (reporting), Portal (tools), and SAP Dev DB/CI (development instance with database/central instance) located at the alternate site.

Alternate processing site:

The hot-site will be located in Philadelphia, PA. It is located 154 miles from the primary facility. The alternate storage facility is a third party storage provider SunGard. This processing site provides redundancy. Points of contact is Jack Fabrianni at 877-456-3966. Those authorized to retrieve media are Don Meltin and Lincoln Balducci at 215-351-1300. The facility will be protected with a badge and password protected lock inside and outside the building. In the case of an emergency like an earthquake, the facility may be unavailable to people outside of the country. The facility has a backup generator in case it loses power. The facility has some satellite phones available in case phone lines are down. There are servers, EDW (enterprise data warehouse), Hyperion Express, UFS (Unix file system), Brio SQR (reporting), Portal (tools), and SAP Dev DB/CI (development instance with database/central instance) located at the alternate processing site. It has SMTP Mail Gateway, File/Print Server, Exchange Mail 2000 Server, Web Server, DNS (Domain Name Services), RAS (Remote Access Services), and PBX (telephone). The site has an 180,000 square foot building with 20,000 square feet of office. Power is provided by PG&E. The telecommunications system is through AT&T. An SLA agreement is in place for telecommunications after 24 hours.

Alternate telecommunications

The vendor for the alternate telecommunications site is AT&T in Reston, VA. Andy Cates is the contact at 877-345-5432. There is another location in Reston, VA. An agreement is in place for a T1 line. The SLA says they only pay when Omega uses it and they will be reimbursed if service is down for longer than 24 hours. The people authorized to implement or use alternate telecommunications capacity are Tim Haney at 619-453-4321 and Linda Okonieski at 503-346-8751.

18

APPENDIX G DIAGRAMS (SYSTEM AND

INPUT/OUTPUT)

19

APPENDIX H SYSTEM INVENTORY

Internal Omega E-mail is supported by a Microsoft Exchange ® 2000 mail server running on a Microsoft Windows ® 2000 Server. Omega has installed an SMTP mail gateway to support Internet mail exchange.

Client machines consist of Microsoft Windows ® 95, 98, NT Workstation 4.0, 2000, and XP. Mac operating systems include OS/8 and OS-X, Panther.

20

List of resources:

-SMTP Mail Gateway

-File/Print Server

-Exchange 2000 Mail Server

-Web Server

-DNS

-RAS

-PBX

-VPN Gateway

APPENDIX I INTERCONNECTIONS TABLE

SAP consists of applications, a database, and other important components which depend on each other to

function. Certain applications will not work if the database is down. The HR application will not work if

the database is down.

APPENDIX J TEST AND MAINTENANCE SCHEDULE

21

Full functional tests will be performed in January and February each year.

Some functional tests will be performed prior to full functional tests. Notification will be email at Reston site. From backup media, will be a recovery of database or a server.

Step Date Due by Responsible Party Date Scheduled Date HeldIdentify failover test facilitator. November 1 ISCP Coordinator October 1Determine scope of failover test (include other systems?).

November 15 ISCP Coordinator, Test Facilitator

October 15

Develop failover test plan. December 1 Test Facilitator November 1Invite participants. January 1 Test Facilitator December 1Conduct functional test. February 1 Test Facilitator,

ISCP Coordinator, POCs

January 1

Finalize after action report and lessons learned.

March 1 ISCP Coordinator February 1

Update ISCP based on lessons learned.

April 1 ISCP Coordinator March 1

Approve and distribute updated version of ISCP.

May 1 ISCP Director, ISCP Coordinator

April 1

APPENDIX K ASSOCIATED PLANS AND PROCEDURES

Version 1.0. The ICSP in a database in Reston. The primary point of contact is ISCP Coordinator Tim Haney.

APPENDIX L BUSINESS IMPACT ANALYSIS

Refer to BIA at Share point site.

APPENDIX M DOCUMENT CHANGE PAGE

Modifications made to this plan since the last printing are as follows:

Record of Changes

Page No. Change Comment Date of Change Signature

This is the first version Tim 1.0.

References

22

Backing Up and Restoring Your SAP System on Windows - SAP NetWeaver by Key Capability - SAP Library. (n.d.). Retrieved from http://help.sap.com/saphelp_nw70ehp2/helpdata/en/85/cd5e76d4b54a0d9463049e0f56f11e/content.htm

Log in to SlideShare. (n.d.). Retrieved from http://www.slideshare.net/haney888/savedfiles?s_title=emergency-handling-for-recovery-of-sap-system-landscapes&user_login=BalakrishnaVegi

23