Managed IT and Cybersecurity for Columbus Churches and Nonprofits

How does Ohio’s data breach notification law treat churches and nonprofits?

The definition section is where this starts. Ohio Revised Code 1349.19 reaches any business entity that conducts business in Ohio, and the statute defines that term as a sole proprietorship, partnership, corporation, association or other group, “however organized and whether operating for profit or not for profit.” A 501(c)(3), a church, a foundation, a private school: the not-for-profit form alone does not put any of them outside it. The section covers computerized data only, not paper files. It also carries exemptions in division (F). Those include HIPAA covered entities, and financial institutions that are both already required to notify customers under federal law and examined by their functional federal regulator for compliance with it. Each exemption has conditions attached. Read 1349.19(F).

Two points about HIPAA are worth being precise on, because organizations get them backwards. The Ohio exemption for a covered entity is categorical, but HIPAA’s own breach rule at 45 CFR 164.404 reaches only unsecured protected health information. A covered entity that loses donor records or card data is not simply trading one rule for the other, and counsel is the right place to sort out what actually covers that data. Separately, the Ohio exemption runs to covered entities rather than to business associates (a counseling program or a nonprofit handling protected health information on behalf of someone else). 45 CFR 164.410 requires a business associate to notify the covered entity of a breach of unsecured protected health information without unreasonable delay and no later than 60 calendar days after discovery. Both sets of duties can land on one organization at the same time.

The Ohio duty turns on two things, and the second one gets missed. First, unauthorized access and acquisition of computerized data holding an Ohio resident’s name together with a Social Security number, a driver’s license or state ID number, or a financial account or card number plus the code or password that unlocks it, where those data elements are not encrypted, redacted, or altered by any method or technology so that they are unreadable. Second, that the breach causes, or reasonably is believed will cause, a material risk of identity theft or other fraud to that resident. When both are true, notice has to reach affected residents in the most expedient time possible and no later than 45 days after the entity discovers the breach or is notified of it, and law enforcement can ask for a delay. If a single breach involves more than 1,000 Ohio residents, notice also runs to the nationwide consumer reporting agencies. The section carries narrow exclusions too. One is good-faith acquisition by the entity’s own employee or agent, and that one holds only where the information is not then used for an unlawful purpose or disclosed further without authorization. Those edges decide real cases, so read the section itself rather than anyone’s summary of it.

Ohio law offers something in return for getting ahead of it. Chapter 1354, commonly called the Ohio Data Protection Act and codified under the heading “Businesses Maintaining Recognized Cybersecurity Programs,” gives an organization that creates, maintains and complies with a written cybersecurity program reasonably conforming to a listed framework an affirmative defense to tort claims alleging that a failure to implement reasonable security controls caused a breach of personal information. The statute frames that as a defense raised under Ohio law rather than immunity, and it is available only where the program exists and is actually followed. Chapter 1354 uses the same not-for-profit-inclusive definition of business, and the qualifying frameworks include the NIST Cybersecurity Framework, NIST SP 800-171, the CIS Critical Security Controls and the ISO/IEC 27000 family.

Two things are worth settling before a program gets built. For an organization that takes cards, PCI DSS on its own does not carry the defense: section 1354.03(C) requires reasonable compliance with PCI DSS together with conformance to one of the other listed frameworks. And the statute expects the current version of whichever framework an organization picks, with a limited window to conform after that framework is revised, so a program left sitting on a superseded edition ages out of the defense. The statute also says the scale of a program can reflect the organization’s size, the sensitivity of what it holds and the resources available to it, which is the part small organizations almost never hear. Extending the defense to other sensitive material, such as pastoral or case notes and volunteer background-check results, means writing the program to cover restricted information as well.

Who is responsible for PCI compliance when donations run through an online giving platform?

Responsibility does not move with the processing. The PCI Security Standards Council states that PCI DSS is intended for all entities that store, process or transmit cardholder data or sensitive authentication data, or that could impact the security of the cardholder data environment. The Council is explicit that outsourcing does not transfer the obligation: the Applicability Notes to Requirement 12.8.1 say that use of a PCI DSS compliant third-party service provider “does not make an entity PCI DSS compliant, nor does it remove the entity’s responsibility for its own PCI DSS compliance.”

Requirement 12.8, which sits in the SAQ A published in January 2025 and effective March 31, 2025, keeps several duties on the merchant’s side of the line. It calls for a list of the third-party service providers in use, with a description of what each one does (12.8.1). It calls for written agreements in which each provider acknowledges responsibility for the account data it handles, or for anything that could impact the security of the merchant’s cardholder data environment (12.8.2). That second limb is the one people skip, and it is what pulls in a website vendor or a church management platform that never touches a card number but can affect a payment page. It calls for an established process for engaging providers, including proper due diligence before signing (12.8.3). It calls for each provider’s compliance status to be reviewed at least once every 12 months (12.8.4). And it calls for a record of which PCI DSS requirements each provider manages, which the merchant manages, and which are shared (12.8.5). Confirming that a provider is PCI DSS compliant for the services it performs is also one of the SAQ A eligibility criteria.

Validating compliance is a separate step from meeting the standard. That validation obligation comes from the acquiring bank and the payment brands rather than from the Council itself, and at the size of a typical church or nonprofit it is usually met with a self-assessment questionnaire. The acquirer determines which SAQ applies, so that is the question to put to yours.

There is a newer wrinkle that catches church and nonprofit websites in particular. Where a giving page is an embedded payment form from a provider sitting inside the organization’s own site, the SAQ A eligibility criteria in the version effective March 31, 2025 call for confirmation that the site is not susceptible to attacks from scripts. The criteria describe two routes to that: protecting the page directly, using techniques like those described in PCI DSS Requirements 6.4.3 and 11.6.1, or obtaining confirmation from a PCI DSS compliant payment processor that its product already protects the payment page when implemented per its instructions. Written confirmation is what gets produced as evidence. Sites that redirect the donor away to the processor entirely are treated differently, and the eligibility criteria at the front of SAQ A spell out which situation is which. Most organizations have never checked what their giving page actually does.

Why would an attacker bother with an organization our size?

Because the payoff is good and the door is usually open. You hold donor names, addresses, giving history, bank and card details, sometimes background check results on volunteers, sometimes pastoral or case notes that would be devastating in public. That data has resale value, but cash is the easier target. The FBI’s 2025 Internet Crime Report logged 1,008,597 complaints and $20.877 billion in reported losses, with business email compromise the second largest loss category at just over $3 billion across 24,768 complaints. A BEC attack breaks nothing. It is one email that looks like it came from the executive director, sent to the bookkeeper, at the moment a real payment is due.

Attackers also do their homework, and a lot of your information is public by design. Charitable organizations that solicit contributions in Ohio generally have to register with the Attorney General before soliciting and refile each year with an annual financial report, and those filings are searchable by the public. ORC Chapter 1716 exempts some organizations from that registration, religious ones among them, and churches are likewise outside the Form 990 that most 501(c)(3)s file and must make available for public inspection. Check ORC 1716.03 for where your organization actually sits. Either way, being exempt from filing does not make you hard to research. A staff directory, a campaign goal and a giving schedule are usually right on your own website. Someone can work out who signs, who pays and roughly what is in the account before writing the first message.

How do we prove multi-factor authentication is actually enforced?

The cyber insurance renewal arrives with a questionnaire, and one of the questions is whether multi-factor authentication is enforced on email, on remote access and on administrator accounts. It is a yes-or-no box, and someone on your staff signs it. In a church or a nonprofit that is a hard question to answer from memory, because the accounts that decide it were created by different people across several years and nobody has ever put them on one page. Whether the answer is yes turns on a list most organizations do not have.

Building that list is the work, and it comes before switching anything on. Every system holding money or member data gets enumerated one at a time, because these platforms do not report into a single console: the Microsoft 365 tenant, the giving platform, the church management system, the bank portal, the administrative logins on the firewall and the wireless. For each account you record which named human is behind it, whether MFA is on, and what the account can reach. The output is a roster with a yes-or-no column next to every line. That is a different thing from an impression that MFA is mostly on.

The roster will not come back clean, and the exception list is what handles that. Something will not support MFA, or supports it in a way that breaks a process the bookkeeper runs every week. So the answer that holds up is the enforced list plus a written record of the exceptions: which accounts are excepted, why, what is in place around each one instead, and when it gets looked at again. That record is what the answer on the form rests on, and it is the same record a board asks for when it wants to know who can reach the money. Keeping it current is ongoing work spread through the year. Onboarding and offboarding under Managed IT and cloud IT services hold the account side of it day to day, and the evidence tracking, control maintenance and renewal support in a virtual CISO engagement keep the documentation from going stale in between.

How do we keep accounts under control when volunteers rotate?

Identity is the control point here. Volunteer churn creates accounts that are easy to make and easy to forget. A shared login for the giving platform. A second shared login for the church management system. Social accounts still signed in on a former volunteer’s phone. An admin password nobody has changed in six years because nobody remembers who set it. Each one is a way in that outlives the person who left. The fix is unglamorous: individual named accounts instead of shared ones, multi-factor authentication on anything that touches money or member data, permissions granted by role, removing access as a written step in the volunteer exit process the same way you collect a key, and a scheduled review of who can still reach financial systems.

That is the daily work of managed IT and cybersecurity services, and the policy, framework choice and board-level reporting around it is what a virtual CISO engagement covers. Before you commit to any of that, it is worth knowing where you actually stand. The Security Analysis is a paid, fully independent assessment, $349, mapped to 38 compliance frameworks. It is a diagnostic: https://outreach.ttscyber.com/analysis