Ohio's Data Protection Act

Most people do not regard their cybersecurity and privacy documentation as a proactive security measure. Documentation is oftentimes viewed as a passive effort that offers little protection to a company as an afterthought that must be addressed to appease compliance efforts.

Where documentation may get some much-needed attention is through Ohio’s recent passing of the Ohio Data Protection Act (ODPA), legislation that supports the premise of properly-scoped cybersecurity and privacy documentation as an offensive tool that can be used to reduce an organization’s risk exposure. This article covers the real-world, strategic advantage of what good cybersecurity and privacy documentation can offer.

The ODPA brings a novel approach to data protection laws in the United States. Unlike earlier Oregon and Massachusetts state data protection laws that contain checklists of mandatory requirements, Ohio passed a law that:

1. Does not create a minimum set of cybersecurity requirements; and 
2. Is optional for businesses to follow.

Yes. You did read that correctly where the law is optional and businesses do not have specific requirements. What Ohio did was allow businesses to be protected from a tort (civil lawsuit) within the state of Ohio that alleges an accused’s “failure to implement reasonable information security controls resulted in a data breach concerning personal information.” In order to be protected by this safe harbor, businesses must align with a leading cybersecurity framework. Ohio went as far as defining several “acceptable” cybersecurity frameworks.

This data protection law is unique since it rests on the concept of affirmative defense that allows a defendant to introduce evidence that, if found credible, can negate civil liability, even if the allegations are true. In practical terms under this law, if a company is sued in the state of Ohio for a legitimate data breach, the lawsuit will get thrown out if the company can prove its cybersecurity program was aligned with a leading cybersecurity framework (e.g., NIST 800-171, NIST 800-53, ISO 27002, CIS CSC, etc.) at the time the incident occurred.

While it applies only to businesses subject to Ohio’s legal jurisdiction, this law may start a national trend that shifts the focus to the business on defining and implementing “what right looks like” for cybersecurity and privacy controls.

There are several reasons this law is appealing to legislators:

1. Legislators do not have to contend with managing their control set as technologies and threats evolve;
2. Legislators get to take credit for being tough on cybersecurity and privacy without actually having to do much;
3. Businesses have no room to complain about unnecessary controls since businesses have the responsibility to define the controls framework that they will use;
4. Businesses can eliminate extra costs by leverage existing audits such as ISO 27001, FedRAMP, NIST 800-171 and PCI DSS to demonstrate compliance; and
5. The court system should see a decrease in civil lawsuits through cases being dismissed by affirmative defense protections.

There are a few downsides to this law, however. These include the following:

1. The injured parties are out of luck for civil damages. The affirmative defense is essentially the state admitting that “sh*t happens,” and injured parties cannot sue when reasonable steps were taken. This may spawn both individual and commercial data protection insurance options for cases where civil damages are unobtainable.
2. While the law identifies acceptable frameworks, it glosses over how an entity can be considered compliant based on “scale and scope” of an entity’s cybersecurity program. The vagueness of the phrase “reasonably conforms to an industry recognized cybersecurity framework” leaves significant room for interpretation.

For businesses that operate in Ohio, it would be advisable to comply with the ODPA. You should start by identifying the correct cybersecurity framework with which to align. Towards that end, you should take into account not only the legal and regulatory obligations that you must comply with but also the compliance obligations that flow down from clients and partners. This scoping exercise also has to take into account third-party service requirements for how that will impact your supply chain.

When you look at factors influencing control adoption, there are a few frameworks that cross industry verticals (shown in the graphic below) that businesses should review for how they impact their internal compliance efforts, as well as what is expected from their clients and supply chain risks:

• NIST Cybersecurity Framework
• NIST 800-171
• ISO 27002
• SOC 2
• EU GDPR
• CCPA (pending CA privacy law)

If you are at a loss for where to start, you may want to look at this model from the Secure Controls Framework:

Gather Pre-Requisites

1. Identify applicable statutory, regulatory and contractual requirements.
2. Identify all geographic locations where data is stored, transmitted and processed.
3. Identify all key stakeholders and third-party service providers.

Narrow the Scope

1. From the coverage provided by the SCF, select only those requirements that are applicable (based on the gathering pre-requisites step).
2. Ignore or delete the other requirements since they are not applicable to your current business model.

Prioritize Controls

1. Using the provided control weighting built into the SCF, prioritize your controls implementation starting with 10 and working towards 1.
2. View this prioritization as a project. You should create a project plan to manage it

Assign Controls

1. Use the SCF’s 32 domains to help with the assignment of controls to the correct teams or individuals.
2. Educate control owners to implement controls based on risk (control weighting) to address the most important controls first

Monitor Controls

1. Require control owners to periodically report on the status of assigned controls and track those metrics.
2. Report metrics to management to identify good/bad trends and to gain support to remediate control deficiencies.