Plan Development Getting from Principles to Paper

Transcription

1 Plan Development Getting from Principles to Paper March 22, 2015 Table of Contents / Agenda Goals of the workshop Overview of relevant standards Industry standards Government regulations Company standards Mapping standards to plan outline Document Control Document control principles Template development Development of different plan types Incident Management Business Continuity Disaster Recovery (data center) Application Recovery Technology Recovery Disaster Recovery Exercise Small Groups plan review and critique Conclusion 2

2 Goals of the Workshop Present an overview of the factors and requirements that shape plan development Give examples of plan development based on these requirements Allow participants to review and critique these examples based on their needs and experience 3 Two Types of Plan Factors External Requirements Factors outside of the plan that determine what will guide, direct, limit its content Regulatory requirements Audit Corporate policy Internal Usability Factors that shape the usefulness of the plan for those reading it Order of content Length Verbiage (or lack of it) Optional content 4

3 Regulations, Policies, and Standards: International Organization for Standardization (ISO) ISO/IEC 2011 All rights reserved 5 Regulations, Policies, and Standards: International Organization for Standardization (ISO) ISO Societal security Business Continuity Management Systems Requirements Supersedes BS 25999, which was withdrawn in 2012 A generic business continuity management standard that can be used by any organization, or any part of an organization, no matter what size it is or what it does However, exactly how you apply ISO is up to you and will depend on your organization's unique business continuity needs and obligations and the particular expectations and requirements of interested parties Plan-Do-Check-Act (PDCA) is an iterative four-step management method outlined in ISO and organized as follows: 1. PLAN - Parts 4, 5, 6, and 7 expect you to plan the establishment of your organization's BCMS. 2. DO - Part 8 expects you to establish your BCMS 3. CHECK - Part 9 expects you to evaluate your BCMS 4. ACT - Part 10 expects you to improve your BCMS. 6

4 Regulations, Policies, and Standards: International Organization for Standardization (ISO) ISO Information technology - Security techniques - Guidelines for information and communication technology readiness for business continuity ISO/IEC provides guidance on the concepts and principles behind the role of information and communications technology in ensuring business continuity. The Standard: Suggests a structure or framework (actually a set of methods and processes) for any organization private, governmental, and non-governmental; Identifies and specifies all relevant aspects including performance criteria, design, and implementation details, for improving ICT readiness as part of the organization s ISMS, helping to ensure business continuity; Enables an organization to measure its ICT continuity, security and hence readiness to survive a disaster in a consistent and recognized manner. 7 Regulations, Policies, and Standards: International Organization for Standardization (ISO) ISO Information technology - Security techniques - Guidelines for information and communication technology readiness for business continuity Plan-Do-Check-Act (PDCA) is an iterative four-step management method outlined in ISO PLAN. Establish a Disaster Recovery Business Continuity policy with objectives, metrics, and processes relevant to managing risk and improving the enterprise's Information and Communication Technology ability and readiness to operate at the level defined within the parameters of the enterprise's overall disaster recovery and business continuity objectives. 2. DO. Implement and operate the Disaster Recovery and Business Continuity policies, procedures, controls, and processes. 3. CHECK. Assess and monitor the performance metrics as defined within the Disaster Recovery and Business Continuity policy metrics and communicate the results to the management of the enterprise. This process can be done via an audit, a test of the plan, or an actual execution of the plan via a post event analysis session. 4. ACT. Modify the Disaster Recovery and Business Continuity policies, procedures, and metrics based on the "Check" (audit, test, or execution of the plan) in order to improve the Disaster Recovery and Business Continuity Policy 8

5 Regulations, Policies, and Standards: Federal Financial Institutions Examination Council (FFIEC) In summary, the following factors represent critical aspects of an effective business continuity planning process: The effectiveness of business continuity planning depends upon the involvement of the board and senior management; Business continuity planning involves a continuous, process-oriented approach that includes a BIA, a risk assessment, risk management, and risk monitoring and testing; A thorough BIA and risk assessment should form the foundation of a comprehensive BCP; The BCP and testing program should be developed on an enterprise-wide basis; The effectiveness of the BCP should be validated through annual, or more frequent, testing; The BCP and test program should be thoroughly documented, evaluated by institution management, independently reviewed by an internal and/or external audit function, and reported to the board; The BCP and test program should be updated to reflect and respond to changes in the institution and gaps identified during continuity testing; and In addition to the BCP, other financial institution policies, standards, and processes should be integrated into the business continuity planning process. 9 Regulations, Policies, and Standards: National Fire Protection Association (NFPA) NFPA National Fire Protection Association (NFPA) Standard on Disaster/Emergency Management and Business Continuity Programs (NFPA 1600). The NFPA 1600 standard is a description of the basic criteria for a comprehensive program that addresses disaster recovery, emergency management, and business continuity. NFPA 1600 is considered by many to be an excellent benchmark for continuity and emergency planners in both the public and private sectors. The standard addresses methodologies for defining and identifying risks and vulnerabilities and provides planning guidelines that address stabilizing the restoration of the physical infrastructure, protecting the health and safety of personnel, and crisis communications procedures. This standard shall establish a common set of criteria for all hazards disaster/emergency management and business continuity programs, hereinafter referred to as the program. This standard provides the fundamental criteria to develop, implement, assess, and maintain the program for prevention, mitigation, preparedness, response, continuity, and recovery. 10

6 Regulations, Policies, and Standards: Health Insurance Portability and Accountability Act (HIPAA) HIPAA Privacy Rule - is a set of federal standards to protect the privacy of patients' medical records and other health information maintained by covered entities: health plans, which include many governmental health programs, such as the Veterans Health Administration, Medicare and Medicaid; most doctors, hospitals and many other health care providers; and health care clearinghouses. These standards provide patients with access to their medical records and with significant control over how their personal health information is used and disclosed. Compliance with the standards was required as of April 14, 2003 for most entities covered by HIPAA. On that date, Office for Civil Rights (OCR) began accepting complaints involving the privacy of personal health information in the health care system. HIPAA Security Rule - establishes national standards for the security of electronic protected health information. The final rule adopting HIPAA standards for security was published in the Federal Register on February 20, This final rule specifies a series of administrative, technical, and physical security safeguards for covered entities to assure the confidentiality of electronic protected health information. The standards are delineated into either required or addressable implementation specifications. Compliance with the standards was required as of April 20, 2005, for most entities covered by HIPAA. The authority to administer and enforce the Security Rule was transferred to OCR on July 27, HIPAA Breach Notification Rule - requires covered entities and their business associates to notify the Secretary, individuals, and in some cases, the media, regarding breaches of unsecured protected health information. Compliance with the standards was required as of September 23, Regulations, Policies, and Standards: Health Insurance Portability and Accountability Act (HIPAA) HIPAA Violation Minimum Penalty Maximum Penalty Individual did not know that he/she violated HIPAA and by exercising reasonable diligence, would not have known. $100 per violation, with an annual maximum of $25,000 for repeat violations. Note: This is the maximum penalty that can be imposed by the State Attorney General regardless of the violation. $50,000 per violation, with an annual maximum of $1.5 million. HIPAA violation due to reasonable cause and not due to willful neglect. $1,000 per violation, with an annual maximum of $100,000 for repeat violations. $50,000 per violation, with an annual maximum of $1.5 million. HIPAA violation due to willfull neglect but violation is corrected within the required time period. $10,000 per violation, with an annual maximum of $250,000 for repeat violations. $50,000 per violation, with an annual maximum of $1.5 million. HIPAA violation due to willful neglect and is not corrected. $50,000 per violation, with an annual maximum of $1.5 million. $50,000 per violation, with an annual maximum of $1.5 million 12

7 Regulations, Policies, and Standards: National Institute of Standards and Technology (NIST) NIST Contingency Planning Guide for Federal Information Systems NIST s Information Technology Laboratory has published a recommended guidance document on contingency planning for federal departments and agencies. (Industry will find the recommendations valuable as well.) NIST Special Publication (SP) , Contingency Planning Guide for Information Technology Systems provides instructions, recommendations, and considerations for government IT contingency planning NIST SP provides guidance to individuals responsible for preparing and maintaining contingency plans. The guide discusses essential contingency plan elements and processes, highlights specific considerations and concerns associated with contingency planning for various types of IT systems, and provides examples to assist readers in developing their own IT contingency plans. 13 Regulations, Policies, and Standards: Company Policy What is your industry? What external standards are referenced? Business Continuity Disaster Recovery Incident Management 14

8 Regulations, Policies, and Standards: Standards Comparison 15 Regulations, Policies, and Standards: Internal Company Policy (cont d) What is required? Business Continuity Plan Application Disaster Recovery Plan Technology Disaster Recovery Plan Incident Management Plan Data Center Disaster Recovery Plan 3 rd Party Vendor (Off-site) Exercise Plan Exercise Report What is measurable? Exercises (types) Applications and Systems Communications Plans Number of; last reviewed or updated What is reportable? Management requirements from Policy 16

9 Regulations, Policies, and Standards: Internal Company Policy (cont d) What is a Policy? A statement of the philosophy, rules, and expectations of the organization Long-term in nature Relatively static Supported and interpreted by more detailed standards, guidelines, and procedures What is a Standard? A mandatory requirement that supports the policy and defines an acceptable level of control along with measurable compliance criteria For Example AIG s policy and standard for a Business Impact Analysis Policy: AIG Business Units are responsible for completing and maintaining a Business Impact Analysis Standard: AIG Business Units are responsible for developing a BIA for all functions/processes which at a minimum identifies: An overview of the overall business purpose A listing of business functions/processes Function/Process location (use multiple line, using the same function/process number) if the function/process is conducted in multiple locations. A summary of potential operational and financial impacts over time 17 Regulations, Policies, and Standards: Internal Company Policy (cont d) For Example - AIG policy and standard for a Business Continuity Plan Policy: AIG Business Units are responsible for completing and maintaining a Business Continuity Plan The BCP identifies the recovery strategy, actions, and activities required to recover business operations during any given operational disruption. Standard: AIG Business Units are responsible to document a BCP aligned to the RA and BIA which must include: Executive Summary Overview of BCP Recovery assumptions RTO for each function/process Staff recovery requirements Key recovery strategy 18

10 Mapping Standards: A Sample Mapping of Standards Requirements to Plan Content 19 Documentation Development and Control: Part 1: Documentation Control Methodology 1. Separate template section (preferably at the beginning of the document) Template information and history Template approval Instructions for completing the template 2. Only approved versions are published/implemented 3. Version numbers 4. Revision history detailed list of changes in each revision 5. Signoff 6. Header, footer, page numbers (content and location of fields should be defined) Good to have! 7. Document title = (Document purpose or subject) + (Applicable entity) or (Applicable entity) + (Document purpose or subject) Order of title may be determined by how documents are to be sorted or stored E.g., AIG Order Processing Application Recovery Plan 8. Filename = (Document title) + (Version number) 9. Version numbering: whole numbers (e.g., 2.00) for approved, published versions; decimals (e.g., 2.03) for intermediate revisions, drafts, etc. 10. Consistent use of effective date : always mm/dd/yyyy format, always linked to current official document version. 20

11 Documentation Development and Control: Part 2: Document Development Methodology Begin by using the agreed-upon document control methodology Identify the drivers of required content and what they require What do the applicable regulations/standards/policies require Consider a content/requirement mapping spreadsheet Determine the order of content More important information at the beginning More detailed explanations later on (e.g., listing of applications vs. application descriptions) Populate the main body of the document with relatively static information Restrict dynamic information primarily to the appendices (team rosters, etc.) Restrict dynamic information to as few sections as possible Use titles and positions in the document rather than individual names Restrict names and contact information to a minimal number of predefined sections Work to keep plans as concise as possible These ideas are helpful! Avoid maps, detailed navigation instructions Provide links where useful Burden of proof is on inclusion, not exclusion Consider a glossary of terms as the final appendix (especially company-specific acronyms) 21 Template Development: Template Section 1 22

12 Template Development: Template Section 2 23 Template Development: Incident Management Plan TOC 24

13 Template Development: Business Continuity Plan TOC 25 Template Development: Disaster Recovery Plan TOC 26

14 Template Development: Technical Recovery Plan TOC 27 Template Development: Application Recovery Plan TOC 28

15 Template Development: Disaster Recovery Exercise Plan TOC 29 Template Development: Sample Appendix for Contact Information 30

16 Template Development: Sample Appendix for Forms and Reporting 31 Template Development: Glossary 32

17 Template Development: Additional Considerations If working with a pre-existing plan, work backward to create a template and documentation standards If using a BC/DR software tool, build a template as a sample plan with a model table of contents Copy the template to form the beginning of a new plan As necessary, create separate TOCs for the template and individual plans that are based on it Use documents for static text and diagrams Use reports for appendices or tables with dynamic information (team listings, contact information, etc.) Regardless of the source of the finished template or plan (BC software, Word, etc.), always proofread and QA the final version 33 Summary of Major Steps in Getting from Principles to Paper Identify the drivers of required content and what they require Legal/regulatory Industry standards Company policy Define a methodology for documentation development and maintenance Identify the types of plans needed Develop a template for each plan type Disseminate and populate the templates Adhere to document management principles and a regular maintenance schedule 34

18 Putting the Work in Workshop : Your Turn Template Evaluation and Critique Each table will get a sample template and a critique worksheet; multiple groups will have the same template Review the template as a group and document your review What would you change about the order of the content? What would you delete from the template? What would you add to the template? We will go around the room and have each group summarize its review 35 Conclusion 36

19 Contact Information David Greb, BCM/Compliance Team Manager Work Phone: Andrew Collins, BCM/Compliance Project Manager Work Phone: Shawn Dennis, BCM/Compliance Project Manager Work Phone: