Presentation on theme: "Business Continuity Program Review 1. TodayTomorrow Disruption Occurs Emergency Response Recovery Stage Business As Usual Planning Stage Normal Operations."— Presentation transcript:
Business Continuity Program Review 1
TodayTomorrow Disruption Occurs Emergency Response Recovery Stage Business As Usual Planning Stage Normal Operations Critical Time Period Business Continuity A Time-Line Perspective EOC Activated
Goal #1 Unsurpassed Undergraduate Education Goal #2 Premier Research University Goal #3 Catholic Character Goal #4 Continuous Improvement Goal #5 Strategic Communication Instruction FacilityITFundingPersonnelSupply ChainAcademic Function 1. Physical Space -Classroom/labs -Resident Halls -Dining Halls -Offices 2. Mechanical -HVAC -Electrical -Plumbing -Maintenance 3. Security -Personnel -Physical (locks) 4. Custodial Svcs 5. Risk Mgmt & Safety 1. Internet Connectivity 2. Data storage & Retrieval 3. Software 4. Hardware Phones 7. IT Security 8. Library 9. Unique/special computers 10. Instructional IT needs 1. Financial Aid / Tuition Mgmt. 2. Payroll 3. Accounts Payable (Vendors) 4. Liquidity 5. Tracking 1. Faculty 2. Administrative Support 3. Oversight -Department -Dean -Provost -Grad. School 4. Human Resources 5. Health & Counseling Svcs 6. Legal Services 7. Campus Ministry 1. Procurement Services -Equipment -Raw product -Office supplies -Other vendors 2. Product receipt storage and delivery Svcs. 3. Hazardous waste disposal services 1. Instruction 2. Enrollment/ Registration 3. Classroom space mgmt. 4. Housing / Residence Life 5. Transcript management 6. Admissions -Undergraduate -Post - Baccalaureate 7. International Studies Infrastructure Needs Instruction Process Needs Aligning BCP With University Goals
Goal #1 Unsurpassed Undergraduate Education Goal #2 Premier Research University Goal #3 Catholic Character Goal #4 Continuous Improvement Goal #5 Strategic Communication Research FacilityITFundingPersonnelSupply Chain Academic Function 1. Physical Space -Labs -Grad. Housing -Offices -Equipment / Specimens 2. Mechanical -HVAC -Electrical -Plumbing -Maintenance 3. Security -Personnel -Physical (locks) 4. Custodial Svcs 5. RM&S 1. Internet Connectivity 2. Data storage & Retrieval 3. Software 4. Hardware Phones 7. IT Security 8. Library 9. Unique/special computers 1. Grant Funding 2. Payroll 3. Accounts Payable (Vendors) 4. Liquidity 5. Tracking 1. Faculty / Researchers (Post-Doc/Grad) 2. Administrative support 3. Oversight -Department -Dean -Provost -Office of Research -Grad School 4. HR 5. Health Svcs 6. Legal Services 7. Camp. Ministry 1. Procurement Services -Equipment -Raw product -Office supplies -Other vendors 2. Product receipt storage and delivery Svcs. 3. Hazardous waste disposal services 1. Research 2. Grant Administration -Pre-Awards -Post-Awards 3. Technology transfer / Intellectual property Infrastructure Needs Research Process Needs Aligning BCP With University Goals
Hierarchy of the University’s Business Continuity Project IRCC Institutional Risk & Compliance Committee Business Continuity Committee Business Continuity Dept Representatives The Business Continuity Committee has been charged with ensuring that plans are developed for essential University departments. The committee is chaired by Micki Kidder (Office of the EVP), administered by Scott Knight (Risk Management & Safety), and includes representatives from the Controller’s Group, Human Resources, Office of Information Technology, Business Operations, and the Provost’s Office. This committee will review and evaluate any major vulnerabilities to identify and resolve potential gaps. The committee will report progress and recommendations to the Institutional Risk & Compliance Committee ( an officer level committee chaired by John Affleck-Graves) and keep the Planning Officer of the EOC informed of all recovery plans.
Kick-Off And Questionnaire Communicate BCP to Operational & Infrastructure Groups. Completion of Bus. Impact Questionnaire BIA Develop BIA’s specific to: 1.IT dependencies 2.Financial dependencies 3.Facility dependencies 4.Other dependencies Develop Recovery Procedures Establish concise action-based recovery procedures for critical processes. Develop Recovery Time Objectives Select groups will identify how long it will take to have their processes back in operation. Storage of Plans: All plan documents are imported into a document management program to manage, manipulate, measure and store indefinitely Gap improvements are made to increase resilience of plans Plans are tested through ongoing exercises and table tops Plans are reviewed and updated on a scheduled basis Business Continuity Planning Flow Chart On-going Complete remaining Documents Complete all remaining elements of their business continuity plans.
Purpose of your Business Impact Questionnaire The responses in your questionnaire will be referenced at each step of the planning process. It will guide your efforts and ensure that we stay aligned with our objectives.
Purpose of the Business Impact Analysis Isolate your critical processes Identify each dependency associated with the critical process (includes its origin and importance ranking) Identify your tolerability‘s Identify implications you face if you are without your dependencies Identify any alternative options you may have in the event that you are without your dependencies “Dependency” = Any service, supply, product, tool or item that is necessary in order for you to deliver your process that is critical to the University. This may be in the form of another department’s deliverable to you, an service or product from an outside vendor or an item or piece of equipment that you own.
What will this information be used for? Prioritization of the University’s recovery efforts Identification of our vulnerabilities Communicating expectations between departments
Process Resumption Procedures Business Continuity Planning
Purpose of Resumption Procedures To expedite the resumption of your critical processes To identify methods for bypassing your dependencies in the event that they are unavailable To assist you with establishing recovery time objectives so that they can be communicated to your stakeholders (our next step)
Setting the stage for Resumption Procedures The Business Continuity Plan is an action-oriented set of documents that effectively transforms, into action, all of the conclusions and judgments that were applied during the information-gathering process. Therefore, these recovery procedures that are based on your business impact analysis should be clear, concise, and well organized. The procedures should take into consideration five key elements that may be needed to deliver your processes: 1. People 2. Facility needs 3. Data/Information technologies 4. Financial processes 5. Supply chains and distribution channels
Strategies for resumption procedures Three core types of recovery strategies 1.Physical solutions -Implemented pre-outage -Example: Duplication of tools (redundancy)/back up generators/use of alternative means of communication (radios)/take measures to head off outages (protect from damages) 2.Operational solutions -Implemented pre-outage -Example: Back-up files / print hard copies of records routinely / make agreements with external providers to carry out your processes for you 3.Response/recovery solutions -Implemented post-outage -Example: Re-allocate personnel and resources to focus on a few processes / Use pencil & paper for record keeping / use foot transportation to distribute your deliverables You can use more than one strategy for the same process
Considerations Personnel needs – Establish calling lists – Establish pre-determined temporary work assignments/roles – Establish decision trees – Cross train staff Facility needs – Always consider ways to allow your activities to be as mobile as possible (ie; go to locations where back-up generators are available or work from home) – Creating stand-by locations to conduct your activities – Identify alternative equipment that can function in the absence of certain utilities (such as electricity) IT needs – Establish alternative communications procedures (radios vs phones, faxes vs , delivery via automobile or walking…) – Back up data bases on a scheduled basis to avoid lost or unretreivable data – Print hard copies of critical data resources on a scheduled basis – Use of flash drives that can be plugged into lap tops Financial process needs – Establish payment deadline lists (for prioritization post-incident) – Ensure that vendors will accept alternative methods of payment or delayed payments – Establish procedures and language to contact payee’s and ask for extensions Supply chain and distribution channel needs – Identify necessary quantities to keep on hand/in stock – Establish vendor lists – Establish alternative vendors for like products (multiple directions and distances) with the philosophy of redundancy – Identify alternative means of transporting goods or services (both incoming and outgoing)
Planning Process In Review Questionnaire development Business Impact Analysis – Identified your needs – Identified your tolerability’s Resumption procedures – Establish detailed plans to resume and recover your processes RTO development – Identification of expected recovery times Critical Document Development – Develop calling lists, vendor lists, inventories, schedules, etc.
Business Continuity Planning Assembling Recovery Teams
What are recovery teams? Recovery teams are groups of employees who will be expected to assemble and work together to recover or resume a particular process. These should be employees with specific technical skills or knowledge needed for the recovery or resumption of the particular process. The teams may be made up of multiple positions and levels, and may include personnel from more than one department. The teams should have a leader present in the field (called “Team Leader”) and should report to a specific Manager, Director or Officer on the progress, needs, and trials and tribulations throughout the recovery phase. It is also important to recognize that there may be personnel who belong to more than one recovery team. It may be helpful to assign people to as few teams as feasible in the event that circumstances and priorities require the resumption of multiple processes at the same time. However, this may be unavoidable for some departmental processes.
Purpose of Recovery Teams By assigning certain people to a recovery effort prior to an incident, we save time and confusion. A set of contact names and numbers will be readily available and we will know we have the correct people working on the correct problems. It allows for the assembly of proper personnel to recover a process even in the absence of a particular leader because this information will be available to your department and officers of the University. It will help to provide a scope for our available (Human) resources during the recovery efforts. It will help departments identify possible conflicts with the uses of their man-power. It will assist with proper communication lines. It will identify back up personnel who can step in, should the primary personnel be unavailable.
Are Recovery Teams required for all processes? No, assembling teams of people to deal with problems may not make sense in many situations. So only assign teams where teams would be needed. In addition, some recovery teams may be needed for specific items or services that are not considered a “process”, rather only one part of a process. Some departments or functional units of the University may have no recovery teams where others may have several. This has more to do with the nature of each process. So it is up to each department or functional unit to decide if creating teams makes sense or not.
How does this fit into the overall BCP Effort? Alignment of Crisis Communications: The teams will have a designated leader who will communicate to a higher level who will ultimately communicate to officers of the EOC to ensure a stream lined path of communications. Ensures that all efforts of the recovery or resumption process align with the University’s goals at the time of the outage event: As priorities are changed by officers of the University, effective shifts in resources can be made. Officers will be able to sort documents by “recovery team” in the event that they need to contact the team to get updates or to re-direct efforts.
What Considerations Are Needed? Reflect on each of your processes and determine if the process is one that needs to be “recovered”, or needs to be “resumed” by bypassing missing items or services, or if both apply. See your “Resumption Procedures” tables. Identify your personnel that have the expertise and experience needed to recover or resume the process. Note that training may be needed to help expedite your overall recovery. Identify secondary personnel who may be able to take over those duties should the primary person(s) be unavailable (unable to reach campus or are busy working on a higher priority process recovery for instance). This may require some cross-training.
What Information Is Needed? 1.Identify the process (or item or service) that will be ‘recovered’ or ‘resumed by alternate means’. 2.Identify the recovery team name (usually the name of the process followed by “recovery team”). 3.Identify the Manager, Director or Officer who oversees this process and would report to the EOC Liaison (ie; the department head). 4.Identify the primary Team Leader who will be in the field, working on the recovery or resumption process. Note that the Team Leader and the Mngr/Dir./Officer can be the same person. 5.Identify the Secondary Team Leader should the primary be unavailable. 6.Identify each of the recovery team members and any secondary members. 7.Provide contact information for each team leader and member. Including home phone, cell phone, and address. Note that this information will be protected and secure. SEE RECOVERY TEAMS TEMPLATE
Business Impact Analysis Part II Recovery Time Objectives 1
Purpose of your RTO table ( Business Impact Analysis Phase II) The purpose of your RTO is to help the Business Continuity Group to identify gaps and vulnerabilities and to provide your stakeholders with realistic expectations.
Defining RTOs The RTO is your Recovery Time Objective. This is an “estimated” time frame that you will be able to recover a particular deliverable such that it is available to your stakeholder(s) based on your current recovery strategies and your technical experience with past or similar outages. We expect some of your RTO’s to change over time as additional resources and advancements in methodology become available in the future. Consequently, RTO’s will be revisited annually. However, at this phase, we ask that the RTO’s be established based on today’s abilities. If the recovery time of your deliverable is dependent upon the availability of other dependencies then please indicate that information in the “assumptions” column of your table (see RTO table). However, you now have available those RTO’s of the infrastructure groups (Utilities, OIT, Controller Groups) and it is expected that you will consider those recovery times when establishing your own recovery times, where applicable. For instance, if you require a certain IT application before you can begin to generate a report that another department needs and OIT’s recovery time to you is 4 hours for that application, then you would need to add 4 hours to your RTO for that report.
Who is developing RTO’s? A compilation of BIA table results have outlined all of the deliverables (items or services) that have been identified with an assigned Maximum Tolerable Outage (MTO) time by a department. Each deliverable will need to be measured against a respective Recovery Time Objective. Consequently, all departments who supply deliverables that have been assigned MTO’s are being asked to provide RTO’s for each of those listed deliverables. A list will be provided to you indicating which deliverables you will need to develop RTO’s for. Some departments will have few, if any. Others will have numerous deliverables to develop RTO’s for.
How to Complete the RTO Table See RTO Table: Column 1: Deliverable– List your deliverable (may be a portion of one of your processes such as one item or service or it may be your entire process) that the RTO represents. See the requested items listed by other departments. Column 2: Customers – This is the department who has developed an MTO for this deliverable (may be several listed, only separate them by rows if you have different RTO’s for each group). Columns 3 and 4: Indicate whether they are an internal (within the University) or external (outside the University) stakeholder. Note, even though an external stakeholder has not been provided to you, if you are aware of a need to include them, please do so. Otherwise, this is meant for future use when we re-visit this table annually. Column 5: RTO – This is where we need a time that you currently feel that this deliverable can be recovered and made available to your respective stakeholder. This may require some additional conversations with other departments of whom you rely on during this process. Time should be given in Hours. Column 6: Assumptions – This can be used for any discretionary need you may have. For instance, your RTO may be reflecting a difficult time of the year when your recovery would likely be slower. Column 7: Changes which can be implemented to improve your RTO – This gives you an opportunity to explain, in general terms, what could be implemented which will serve to improve your RTO, such as additional resources that you currently do not have available. This may serve to expedite the gap resolution process. Note: If your deliverable can only be provided to a limited number of stakeholders and you are faced with a decision as to which stakeholder is given priority, please contact Scott
How will gaps be evaluated IRCC Institutional Risk & Compliance Committee Business Continuity Committee Business Continuity Dept Representatives When RTO’s are found to be longer than departmental MTO’s they will be red-flagged, indicating that a “gap” has been identified. This can be described as a department not receiving an item or service in the amount of time that they are depending on receiving it. This will be considered a vulnerability for the University. When gaps are identified by the Working Group of the Business Continuity Committee, each functional unit tied to that gap (both the MTO provider and the RTO provider) will be involved in a discussion and asked to identify alternative options to resolve the gap. If a resolution is not established then each group will be asked to develop a report which explains the options that may be considered which would serve to close the gap. The MTO group will seek ways to extend their MTO time while the RTO group will seek ways to speed up their RTO time. If additional resources are deemed necessary, costs and timeframes for implementation will need to be provided. Ultimately, significant decisions will be made by the IRCC. They may opt to take one of the proposed options or to defer the gap resolution to a later date.
Remaining Steps Departmental Contact Information Supplier Information Contractor Information Business Continuity Planning Committee to assess all gaps and conduct gap resolution process On-going: – Updating information and reflecting changes – Testing of plans/ Table tops and drills – Continuous plans to improve