The major cloud computing platforms are more secure than the average on-premises infrastructure deployment. But “more secure” isn’t the same as “sufficiently secure.” Cloud security is a shared responsibility: cloud vendors provide the foundations, but it’s up to cloud customers to build secure systems. That’s unlikely to happen without a well-documented, comprehensive, and enforced cloud security policy (CSP). A cloud security policy sets security parameters for managers and employees, and that’s essential if your business is to avoid expensive, compliance-busting security mistakes. 

What Is a Cloud Security Policy?

A cloud security policy formally states an organization’s intentions and directives applicable to security on cloud platforms. Cloud security policies tell executives, employees, and other stakeholders what the organization expects of them as they use cloud services. They provide a high-level framework that guides day-to-day cloud operations and a security-focused structure for implementing cloud-based projects. 

We all use the term “cloud” to refer to a particular type of computing environment, but, in reality, the cloud is heterogeneous. There are many kinds of cloud and cloud services: IaaS, PaaS, SaaS, cloud storage, cloud databases, and cloud machine learning services, to name just a fraction. Each vendor and service has security best practices, so organizations should develop custom cloud computing security policies that reflect their real-world cloud use. 

Does Your Business Need a CSP?

You may be wondering why your organization needs a cloud security policy. You need secure systems, but does that require a documented policy? Can’t you rely on your team to follow security best practices? Although that may seem viable, it doesn’t work in practice. 

  • Executives and employees prioritize speed, efficiency, or cost if security isn’t officially mandated and supported by executives.
  • Teams and business units lacking a framework tend to implement ineffective ad-hoc security practices.
  • Partners and service users expect your organization to demonstrate a coherent security policy, particularly if they entrust you with sensitive data.
  • Many information security standards and regulations expect organizations to produce a documented cloud security policy.

Many cloud security breaches and data leaks result from employees using cloud platforms insecurely. For example, businesses leak millions of secure records every year because cloud storage and databases are left open to public access. This is sometimes the result of ignorance, but it’s often done to expedite data sharing with internal and external stakeholders. A documented cloud data security policy with rigorous training and data management requirements minimizes data leaks by motivating employees to do the right thing. Cloud security policies can also document sanctions for those who put data at risk, giving Human Resources professionals and managers recourse when employees behave contrary to cloud best practices. 

A documented cloud security policy has advantages beyond fostering improved internal security practices. It also demonstrates to third parties that your organization takes security seriously. Customers want assurance their data is safe on your platform. Every business claims to follow cloud security best practices, but the frequency of catastrophic data leaks makes customers look askance at those claims. A cloud security policy can diminish their concerns by demonstrating your understanding of the risks and the controls implemented to mitigate them. Many companies create an abridged version of their cloud security policy for this purpose. 

Third-party certifications and reports further increase the customer’s confidence. Security standards such as ISO 27001 and SOC 2 require organizations to create security policies and document controls. The same is true of regulatory frameworks like HIPAA and GDPR. Undergoing audits and attaining security certifications is only possible if your business has done the work to create rigorous security policies in line with accepted best practices. KirkpatrickPrice’s cloud security audit is based on the CIS Benchmarks, an excellent starting point for organizations looking to implement effective cloud security policies.

What Should You Include in a Cloud Security Policy?

Organizations should customize cloud security policies —no two businesses use the same mix of cloud vendors and services. Additionally, organizations have varying compliance requirements, and cloud security policies should be shaped to address them. It is often helpful to have multiple cloud security policies, each concerning a separate business area or a distinct cloud security concern. However, most organizations should include policies that impact the following areas:

  • Which data can be uploaded to the cloud, and how should it be protected
  • Risks for each type of data and how they are to be mitigated
  • Who is authorized to use cloud platforms and the constraints they operate under
  • Cloud use and how it should conform to compliance objectives
  • Planned responses to security threats and data breaches
  • Logging and monitoring objectives

Organizations can draft the cloud security policy document to meet their needs and documentation standards, but the following summarizes a widely used cloud security policy template.

  • Purpose: Outline what the policy is intended to achieve. For example, it might be a policy to ensure the confidentiality and privacy of sensitive data.
  • Policy scope: Which data and systems does the policy cover, and which hardware, software, and other relevant systems are within scope?
  • Data types: The categories of data covered by the policy, e.g., financial data, personally identifiable information, intellectual property, and sensitive proprietary information.
  • Ownership: To whom does the policy apply, and what are their responsibilities? This might include the individuals who use the cloud service, the person responsible for ensuring security best practices are followed, and the person in overall charge of cloud use decisions.
  • Permitted services: Which cloud services are approved for storing and processing the data described above? This section might include cloud vendors (AWS, Azure, GCP) and individual services offered by those vendors (AWS S3, SimpleDB, EBS, etc.)
  • Denied services: Services that should not be used. The use of unauthorized services is a common cause of cloud vulnerabilities. This section may prohibit all cloud services not on the Permitted Services list.
  • Acceptable use of cloud services: Establish acceptable use criteria for adopting cloud services. This section describes under which circumstances cloud platforms can be used and the processes that must be followed.
  • Cloud inventory: How does the organization intend to track cloud infrastructure and its data? Because it’s easy to deploy cloud infrastructure, businesses often lose track, leaving sensitive data at risk on unmonitored services.
  • Risk assessment: Delineate the risk assessment process to be completed before adopting a cloud service or making a significant change to the cloud infrastructure configurations.
  • Security controls: Describe the controls that the organization will implement to mitigate risk and protect data. The CIS Benchmarks and CIS Controls are helpful starting points when deciding which controls to include.
  • Security incident response: How will your organization respond to and recover from security incidents? This section may include incident reporting requirements, data recovery priorities, and systems to facilitate recovery.
  • Policy enforcement: How will the above policies be enforced? Enforcement is a critical aspect of your cloud security policy. Detail specific penalties for failure to comply.
  • Training: Your cloud security policy is useless if employees don’t know about it and their role in its implementation. This section mandates training processes that include onboarding and security awareness training.

Secure Your Cloud with KirkpatrickPrice

KirkpatrickPrice offers a range of cloud security services to help businesses build secure and compliant cloud environments, including: 

Enhance your cloud security today with a free cloud security scan, or contact a cloud compliance expert to create a cloud security policy that proactively protects your organization’s cloud environment.

Unfortunately in today’s modern threat landscape, it’s only a matter of time before your business faces a disaster. How would your organization cope if an employee deleted a production database? Could you continue to serve customers if a tornado took out your primary data center? How soon could you recover data encrypted in a ransomware attack or return to normal operations during a denial-of-service attack? Disaster recovery planning ensures your business has answers to these questions and more. 

We covered disaster recovery planning basics in What is a Disaster Recovery Plan (DRP)? In this article, we’ll explore the disaster recovery planning process and the steps you need to take to build a robust DRP that protects your business’s infrastructure from real-world threats. 

Why Do You Need a Disaster Recovery Plan?

Disaster recovery planning lays the groundwork to help your business bounce back when things go wrong. It’s only a matter of time before an adverse event threatens to disrupt business operations. A DRP may make the difference between a quick recovery with minimal losses and a catastrophe costing your business thousands or even millions of dollars. It’s not unusual for companies to go out of business after a large data loss or severe service disruption—a realistic and practical disaster recovery plan might have saved them. 

Other benefits of disaster recovery planning include the following:

  • Preventing the loss of customers to competitors. Consumers have little patience for extended downtimes, especially for online services. It doesn’t take long for previously loyal customers to seek alternative vendors, and once they’ve found a suitable replacement, they are unlikely to return.
  • Limiting reputation damage. People remember large-scale data losses and service disruption. They introduce a degree of doubt that can dissuade potential customers from adopting your services for many years.
  • Enhancing compliance. Disaster recovery planning is part of many security standards and regulations, including HIPAA, SOC 2, and ISO 27001.
  • Improving infrastructure transparency. Disaster recovery planning forces businesses to catalog their infrastructure and the services it hosts. This is a useful exercise: many security vulnerabilities result from improperly monitored and secured infrastructure.

Identify Critical Infrastructure and Services

An organization must comprehensively understand its infrastructure and the services it supports before designing disaster recovery processes. An infrastructure inventory is often one of the most time-consuming aspects of disaster recovery planning, but it is necessary. You can’t build redundancies, failovers, and risk mitigation systems unless you have a clear and comprehensive accounting of what you’re protecting. 

It’s not unusual for businesses to build a disaster recovery plan that ignores essential pieces of the puzzle: for example, an old server running scripts that no one has looked at for years but which turn out to play a critical role in keeping services up and running. A complete infrastructure inventory mapping essential services will help you to build robust disaster recovery processes. 

Conduct a Risk Assessment

A risk assessment documents and prioritizes risks to a business’s operations. Simply put, risk is the likelihood of something bad happening. Risk has two components: adverse events and their probability. A risk assessment identifies adverse events that could disrupt operations and considers how likely they are. For example, businesses have a high likelihood of disruption due to ransomware attacks, so mitigation and disaster efforts should be prioritized. 

Conducting a systematic risk assessment is often challenging for businesses, especially when they lack the expertise to identify risks and the probability of an adverse impact. A risk assessment’s utility may be affected by ‘unknown unknowns,’ factors you cannot account for without expertise and experience in the relevant field. It may be beneficial to hire a third party that specializes in systematic risk assessments. 

Determine Disaster Recovery Objectives

The next step is to prioritize systems and determine your disaster recovery objectives. Objectives are usually expressed as Recovery Time Objectives (RTO) and Recovery Point Objectives (RPO). RTO is how quickly you would like systems to be back online in the event of a failure. To put it another way, how much downtime is acceptable? RPO expresses how up-to-date you expect recovered data to be. For example, are you comfortable losing a couple of hours of data, or do you need guarantees that there will be as little data loss as possible? 

Your RPO and RTO decisions impact disaster recovery systems’ design, implementation, and cost. Typically, critical systems will be given low RTO and RPO times. They should be recovered as quickly as possible with the least data loss. You might choose to deploy redundant infrastructure with automatic failovers and continuous backups for these systems. Higher RTO and RPO values are acceptable for less critical systems—you may be content to leave low-priority systems offline for several hours with daily or even weekly data backups. 

Create Written Policies and Documentation

At this point, you understand your IT infrastructure’s risks, how to prioritize disaster recovery planning, and your disaster recovery objectives. The next step is to create disaster recovery policies to achieve those objectives. From those policies flow specific processes and procedures. These should be comprehensively documented as documentation is critical to effective disaster recovery. Managers and employees must understand what’s expected of them and the available resources. 

At a minimum, your disaster recovery plan documentation should include the following:

  • Procedures for recovering and restoring systems
  • Inventories of disaster recovery infrastructure and services
  • Schedules that order procedures according to the importance of each system
  • Lists of responsible employees: who takes charge of disaster recovery, is accountable for implementing DR procedures, is tasked with customer and partner liaison, and so on. Documentation should include contact details for all responsible individuals.

Test, Revise, and Adapt

Once your disaster recovery plan is in place, it should be tested to make sure it survives within the real world. A plan is a great starting point, but it’s far better to discover a shortcoming during testing than a serious incident. Run simulations, test DR infrastructure, and enact disaster recovery drills with employees. During testing, you will discover opportunities for improvement, which should feed back into your policies, procedures, and documentation. 

Regularly Update Your Disaster Recovery Plan

Your company’s IT infrastructure and processes evolve, and your disaster recovery plan should evolve with them. DR planning is not a “once and you’re done” event. Businesses must iterate on their plan continuously, ensuring that policies and documentation reflect current systems and priorities. It would be unfortunate if, when disaster strikes, employees turn to their DR plan only to find that it’s years out of date and inapplicable to the current scenario. 

Does Your Disaster Recovery Plan Comply With Information Security Regulations?

We mentioned earlier that information security regulations and standards often require disaster recovery planning. But there is another aspect of compliance to consider. Your business’s DR infrastructure and processes must also be compliant. They must have the same security, confidentiality, privacy, and data protection controls as your primary infrastructure. 

KirkpatrickPrice offers a wide variety of information security testing and auditing services that help businesses to maintain compliant disaster recovery plans, including audits for:

To learn more, contact a KirkpatrickPrice information security specialist today.

Jama Software is the only vendor in the requirements management and traceability space that is SOC 2 Type II compliant both on the application layer and the data center offerings. 

PORTLAND, Ore., USA, Nov 8, 2022 – Jama Software¼ , the leading requirements management and traceability solution provider, today announced that it has completed its SOC 2 Type II audit, performed by KirkpatrickPrice. This attestation provides evidence that Jama Software has a strong commitment to security and to delivering high-quality services to its clients by demonstrating that they have the necessary internal controls and processes in place. 

A SOC 2 audit provides an independent, third-party validation that a service organization’s information security practices meet industry standards stipulated by the AICPA. During the audit, a service organization’s non-financial reporting controls as they relate to security, availability, processing integrity, confidentiality, and privacy of a system are tested. The SOC 2 report delivered by KirkpatrickPrice verifies the suitability of the design and operating effectiveness of Jama Software’s controls to meet the standards for these criteria.  

 “We take great pride in being the first and only multi-tenant, pure-SaaS offering in our space and now with SOC 2 compliance, Jama Connect customers have additional validation and confidence that they are getting unparalleled best-in-class security, business continuity, and can further mitigate risks and scale with compliance,” said Marc Osofsky – Chief Executive Officer of Jama Software.  

“The SOC 2 audit is based on the Trust Services Criteria,” said Joseph Kirkpatrick, President of KirkpatrickPrice. “Jama Software delivers trust-based services to their clients, and by communicating the results of this audit, their clients can be assured of their reliance on Jama Software’s controls.” 

If you wish to learn more and start using Jama Connect Click here  

_______ 

About Jama Software: 

Jama Software is focused on maximizing innovation success. Numerous firsts for humanity in fields such as fuel cells, electrification, space, autonomous vehicles, surgical robotics, and more all rely on Jama Connect¼ to minimize the risk of product failure, delays, cost overruns, compliance gaps, defects, and rework. Jama Connect uniquely creates Live Traceabilityℱ through siloed development, test, and risk activities to provide end-to-end compliance, risk mitigation, and process improvement. Our rapidly growing customer base of more than 12.5 million users across 30 countries spans the automotive, medical device, life sciences, semiconductor, aerospace & defense, industrial manufacturing, financial services, and insurance industries. Visit us at jamasoftware.com. 

 

About KirkpatrickPrice: 

KirkpatrickPrice is a licensed CPA firm, PCI QSA, and a HITRUST CSF Assessor, registered with the PCAOB, providing assurance services to over a thousand clients in North America, South America, Asia, Europe, and Australia. The firm has more than a decade of experience in information security by performing assessments, audits, and tests that strengthen information security practices and internal controls. KirkpatrickPrice most commonly performs assessments on SOC 1, SOC 2, PCI DSS, HIPAA, HITRUST CSF, GDPR, ISO 27001, FISMA, and FERPA frameworks, as well as advanced-level penetration testing. For more information, visit www.kirkpatrickprice.com. 

 

____ 

 

Media Contact 

Karrie Sundbom  

Senior Director, Marketing, Jama Software 

marketing@jamasoftware.com 

 

A revised version of ISO 27001 is expected this fall. When standards change, it’s natural for organizations to wonder whether it will impact their operations and compliance. Organizations about to undertake an ISO 27001 audit may hesitate until the new standards are published. 

In fact, the changes to ISO 27001 will not have an immediate impact on compliance, and there is no reason to postpone audit preparation. However, a new version of ISO 27002 was published earlier this year. The included changes will be replicated in the upcoming revisions to Annex A of ISO 27001, affecting future compliance efforts. 

In this article, we’ll explore what ISO 27001 is, how it’s different from ISO 27002, and the likely impact of the revised ISO 27001 and ISO 27002 standards. 

What is ISO 27001?

ISO/IEC 27001 is an international information security standard. It was developed as a solution to the problem of ad-hoc information security implementation. Organizations would implement controls to patch security in response to incidents, but they would not implement an overarching system that adequately accounts for potential risks. 

ISO 27001 describes security controls that, when implemented, constitute a comprehensive information security management system. It also provides a framework that auditors can use to certify that an organization complies with widely accepted standards for information security. 

The standard consists of sections that outline expectations for information security implementation. For example, Clause  4.4 requires an organization to establish, implement, and continually improve an information security management system. Clause  6.1.2 requires organizations to identify, analyze, and evaluate information security risks. 

In addition to the clauses, ISO 27001 includes Annex A, which lists specific control objectives and controls. There are dozens of paired objectives and controls, but let’s look at a few to get a clear idea of what’s expected. 

  • A.9.4.3 — Objective: Password management system. Control: Password management systems shall be interactive and shall ensure quality passwords. 
  • A.10.1.1 — Objective: Policy on the use of cryptographic controls. Control: A policy on the use of cryptographic controls for the protection of information shall be developed and implemented.
  • A.12.1.2 — Objective: Change management. Control: Changes to the organization, business processes, information processing facilities, and systems that affect information security shall be controlled.

The most substantial changes in the updated version of ISO 27001 are to the Annex A controls. We’ll see which controls have changed in a moment, but first, let’s look at the relationship between those controls and ISO 27002. 

What Is the Difference Between ISO 27001 and 27002?

ISO 27001 is the standard that organizations can be certified against. But, as we’ve just seen, the objectives and controls included in ISO 27001 Annex A are vague and non-specific. They don’t include any implementation details. That’s because organizations can choose how to implement the controls, provided their implementation meets the requirements, and document how the implemented controls map to the objectives in Annex A.

 ISO 27002 includes the “missing” implementation guidance.  It lists the same controls as ISO 27001 but provides more information and guidance to those seeking to implement the applicable controls. The implementation guidance doesn’t get into the technical details, but it does outline clear and detailed requirements for any compliant system. In the previous section, we quoted the password management system objective from ISO 27001 (A.9.4.3).  ISO 27002 has an equivalent section that goes into greater detail about what’s expected. The password system must enforce the use of individual IDs, allow users to change passwords, not display passwords on the screen, store passwords in a protected form, and so on.

It’s important to understand that an organization doesn’t have to follow the implementation guidelines in ISO 27002. It can use different information security standards, provided they can be mapped to the controls in ISO 27001 Annex A. That’s one reason there is no such thing as an ISO 27002 certification. ISO 27002 is a supplementary standard to help organizations comply with ISO 27001 and achieve certification. 

How Did ISO 27001/ISO 27002 Change in 2022?

ISO 27002 was updated at the beginning of 2022. New controls and control categories were added, and some control categories were consolidated. ISO 27002 provides implementation guidance for the controls included in ISO 27001 Annex A, so the updates necessitate changes to align Annex A with the controls in the implementation guidance. 

What Are the New Controls for ISO 27001?

There are 11 new controls in ISO 27002:2022, so we can expect the same new controls in Annex A of ISO 27001. They include:

  • Threat intelligence
  • Information security for use of cloud services
  • ICT readiness for business continuity
  • Physical security monitoring
  • Monitoring activities
  • Web filtering
  • Secure coding
  • Configuration management
  • Information deletion
  • Data masking
  • Data leakage prevention

Although controls have been added, the total number has reduced from 114 to 93. That’s because several controls have been merged. The categories have also been consolidated and merged. In ISO 27001:2013, the controls were divided into 14 different areas. In ISO 27001:2022, there will be four domains. 

  • People controls: remote work, confidentiality, non-disclosure, screening, etc. 
  • Organizational controls:  organizational information policies, cloud service use, asset use, etc. 
  • Physical controls: security monitoring, storage media, maintenance, facilities security, etc. 
  • Technological controls: authentication, encryption, data leak prevention, etc. 

To see a full list of the changes expected in ISO 27001: 2022, consult the controls and guidance in ISO 27002:2022. 

How To Prepare for ISO 27001:2022

Your organization does not need to make immediate changes, although you should familiarize yourself with the new and revised controls. If your information security management system is based on the implementation guidance in ISO 27002, you should put plans in place to update controls, if required. If you use a different set of standards, you will be expected to provide documentation mapping from your chosen controls to the controls in ISO 27001:2022 Annex A. 

Should My Organization Delay ISO 27001 Certification?

There is little reason to delay ISO27001 certification until the updated version is released. If your organization or its customers require an ISO 27001 audit or certification, waiting may not be beneficial to your business. There is likely to be a three-year transition period before documentation edits and control implementation are required to comply. 

Work With KirkpatrickPrice to Achieve Your ISO Certification

KirkpatrickPrice offers ISO 27001 audits and consulting services that help our clients to achieve ISO 27001 compliance. We will help you to identify, qualify, and catalog information security risks in your environment and provide the support you need to implement a compliant information security management system. Contact an information security specialist to learn more about our ISO 27001 compliance services.

Man working on computer

In 2022, businesses are reliant on IT infrastructure. Whether it’s on-premises, cloud, or outsourced infrastructure, IT supports day-to-day business operations, customer interactions, human resource management, communications, sales and marketing, financial management, web and mobile services, and more. Unexpected downtime in these areas can severely impact operations and cost thousands of dollars every minute.  Has your business planned for how to deal with these kinds of threats?

To prepare for such attacks, your organization needs to have a documented Disaster Recovery Plan (DRP). A DSP is a documented policy detailing an organization’s planned response to unexpected events that disrupt IT infrastructure and operations. DRPs document actions, processes, and systems to re-establish service availability while maintaining security and compliance. Organizations create DRPs to reduce downtime and the potential for financial loss in the face of catastrophic disruption. DRPs also play a key compliance role: many information security regulations and standards require businesses to plan for disaster recovery. 

This article explores disaster recovery plans, the part DRPs play in business continuity planning, and the relationship between disaster recovery planning and compliance. 

What is a Disaster Recovery Plan?

Because businesses depend on IT infrastructure, they are threatened by potential disasters ranging from cybercrime attacks and human error to power outages and tornadoes. A disaster recovery plan is a hedge against risk. Businesses consider potential risk scenarios and implement plans and policies to limit their impact. 

There are obvious financial and operational incentives for creating and maintaining disaster recovery plans. The Uptime Institute’s Outage Analysis for 2022 found that over 60% of IT outages result in losses exceeding $100,000. One in five organizations reported a serious or severe outage in the last three years, and 80% of data center operators reported outages of similar severity. If your business relies on IT infrastructure, it makes sense to plan for disruption. 

Disaster recovery planning aims to provide documented processes employees can follow when the worst happens. Employees should know their roles and responsibilities, the processes they are expected to follow, and how the business plans to overcome IT availability challenges. DRPs also outline technological solutions to downtime, including implementation and maintenance procedures to ensure backups and redundancies work when needed. 

At the policy level, a business may have a single document detailing its disaster recovery policies: its goals for disaster recovery. However, all but the smallest businesses should have multiple disaster recovery plans covering various business operations. For example, a business might have independent disaster recovery plans covering:

  • Data center infrastructure
  • Communication systems
  • Cloud and virtualized infrastructure
  • Network disruptions
  • Cyberattacks and data theft

Although there may be some overlap, each of these scenarios requires a unique response and, therefore, a unique disaster recovery plan. 

Disaster Recovery vs. Business Continuity: What’s the Difference?

Disaster recovery and business continuity are related but distinct responses to risk. Disaster recovery planning is limited to IT infrastructure and resources. It concerns preparations for IT outages and downtime, temporary measures to maintain availability when infrastructure is disrupted, and how the organization plans to recover IT operations to their original state. 

Business continuity planning is broader in scope than disaster recovery planning. It concerns all policies and procedures related to a company’s continued operation during a disruptive event. For example, business continuity plans might include responses to supply chain disruption, pandemics, financial fraud, property theft, the outbreak of war, and so on. 

Disaster recovery planning is typically considered a subset of business continuity planning concerning IT infrastructure. Forward-thinking businesses make business continuity plans for realistic threat and risk scenarios. Plans that focus on IT infrastructure and service availability are called disaster recovery plans. 

Disaster Recovery Planning and Compliance

Many IT and information security regulations and standards mandate disaster recovery planning. There are two main compliance concerns relevant to disaster recovery:

  1. Regulations and standards may require organizations to demonstrate they have implemented effective disaster recovery planning.
  2. Disaster recovery processes and the associated IT infrastructure must comply with information security, privacy, and confidentiality compliance requirements. 

Let’s explore the specific requirements per the different security regulations and standards: 

HIPAA

The Health Insurance Portability and Accountability Act (HIPAA) requires organizations that store electronic protected health information (ePHI) to implement contingency plans, including disaster recovery plans, data backup plans, and emergency operation mode plans. Organizations must be able to recover critical IT systems that store and process PHI in the event of a disruptive incident. As you might expect, all redundant and failover infrastructure implemented as part of a disaster recovery plan must also be HIPAA-compliant. 

SOC 2

A SOC 2 audit verifies that businesses comply with the common criteria of the Trust Services Principles, which are primarily related to information security. However, businesses may also need to comply with additional criteria, including availability, confidentiality, processing integrity, and privacy. The availability criteria address disaster recovery planning and testing. 

Key criteria include A1.2 and A1.3. The former requires organizations to develop, implement, operate, and maintain data backup processes and recovery infrastructure. The latter requires organizations to test recovery plan procedures that support system recovery.  

ISO 27001

ISO 27001 Annex 1.17 focuses on infrastructure redundancy and security continuity. A.17.2.1 concerns the availability of information processing facilities with requirements for redundant infrastructure and testing. A.17.1.1-3 concerns information security continuity and an organization’s ability to maintain information security during disruptive events. Together they require compliant organizations to plan, implement, and evaluate information security continuity policies and processes. 

PCI DSS

The Payment Card Industry Data Security Standard (PCI DSS) does not require disaster recovery planning, but it does include several requirements that impact planning for disasters.  Requirement 12.10 concerns creating and implementing an incident response plan for security breaches. Requirement 9.5.1 addresses storing media backups in secure off-site facilities and periodically reviewing backup security. As with other standards, all infrastructure used for disaster recovery must also be compliant. 

What Should Be Included in a Disaster Recovery Plan?

Disaster recovery plans should be uniquely tailored to each organization and its IT infrastructure. There is no simple disaster recovery plan template that applies to every organization. In fact, your disaster recovery should not be the same in a year as it is today—it must evolve as your business and its infrastructure evolves. 

However, all disaster recovery planning processes should include the following components:

  • Recovery time objectives (RTO): How quickly should services be restored to an acceptable level after an incident? 
  • Recovery point objectives (RPO): What level of data loss is acceptable to your organization?
  • IT Inventory: A complete and up-to-date inventory of IT infrastructure and cloud services your business relies on. 
  • Risk assessment: A thorough assessment of realistic risks and their potential impact. 
  • Personnel responsibilities: Who is responsible for implementing disaster recovery plans; it is vital that roles and responsibilities are clearly documented and that personnel are adequately trained.
  • Disaster recovery and restoration processes: A detailed breakdown of actions to be taken and the resources required to achieve the business’s RTOs and RPOs. 

Validate Your Disaster Recovery Compliance with KirkpatrickPrice

As we’ve discussed, many information security regulations and standards touch on disaster recovery planning. Is your organization certain its disaster recovery plans and systems are secure and compliant? A KirkpatrickPrice compliance audit can assure you that your plans are sufficient and effective for your specific business needs.  As a licensed CPA firm, KirkpatrickPrice’s experienced information security experts carry out a wide range of compliance audits, including:

To learn more, contact a KirkpatrickPrice information security specialist today.