Managed IT and Cybersecurity for Columbus Churches and Nonprofits
You hold names, addresses, giving history and bank details for people who trusted you with them, and you run it all on a budget written for the mission rather than for IT. The person who manages your church management system, your giving page and your Microsoft 365 tenant is often a staff member with three other jobs, or a volunteer who is generous with time and unfamiliar with security. Attackers know both of those things.
Does Ohio’s data breach notification law apply to churches and nonprofits?
Yes, for most of them. 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) — including for HIPAA covered entities, and for 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), or ask us to walk your situation through it.
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, so get counsel on what actually covers that data. Separately, if you are a business associate rather than a covered entity — a counseling program or a nonprofit handling protected health information on behalf of someone else — you do not get the Ohio exemption, and 45 CFR 164.410 requires you 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 duties can land on you 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 you discover the breach or are notified of it, and law enforcement can ask you to delay. If a single breach involves more than 1,000 Ohio residents, you also have to notify the nationwide consumer reporting agencies. The section carries narrow exclusions too — good-faith acquisition by your own employee or agent, for one, but 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 gives you something back 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. That is a defense you raise under Ohio law, not immunity, and it only works if the program exists and you actually follow it. 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 to settle before you build one. If you take cards, PCI DSS on its own does not get you there: section 1354.03(C) requires that you reasonably comply with PCI DSS and conform to one of the other listed frameworks. And the statute expects the current version of whichever framework you pick, 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 your program can reflect your size, the sensitivity of what you hold and the resources available to you, which is the part small organizations almost never hear. If you want the defense to reach the other sensitive material you hold, such as pastoral or case notes and volunteer background-check results, write the program to cover restricted information as well.
Who is responsible for PCI compliance if we use an online giving platform?
You are, at least in part. 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 your side of the line. Keep a list of the third-party service providers you use, with a description of what each one does for you (12.8.1). Keep written agreements in which each provider acknowledges responsibility for the account data it handles, or for anything that could impact the security of your 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 your payment page. Have an established process for engaging providers, including proper due diligence before you sign (12.8.3). Review each provider’s compliance status at least once every 12 months (12.8.4). And keep a record of which PCI DSS requirements each provider manages, which you manage, and which are shared (12.8.5). Confirming that your provider is PCI DSS compliant for the services it performs is also one of the SAQ A eligibility criteria.
You also have to validate your own compliance. That validation obligation comes from your acquiring bank and the payment brands rather than from the Council itself, and for an organization of your size it is usually met with a self-assessment questionnaire. Ask your acquirer which SAQ applies to you.
There is a newer wrinkle that catches church and nonprofit websites in particular. If your giving page is an embedded payment form from a provider sitting inside your own site, the SAQ A eligibility criteria in the version effective March 31, 2025 require you to confirm your site is not susceptible to attacks from scripts. You meet that either by protecting the page yourself, using techniques like those described in PCI DSS Requirements 6.4.3 and 11.6.1, or by obtaining confirmation from your PCI DSS compliant payment processor that its product already protects your payment page when implemented per its instructions. Get that confirmation in writing, because it is the evidence you will be asked for. 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. Send us the page and we will tell you.
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. The money is easier to take than the data, though. 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 keep accounts under control when volunteers rotate?
Treat identity as the control point rather than the network. 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, not a sales call: https://outreach.ttscyber.com/analysis
Start here
Find out where you actually stand
The Security Analysis is a fixed-scope review of your environment, run independently and mapped to 38 compliance frameworks. It is the fastest way to replace an assumption about your posture with a finding.
Questions we get asked
Our data is in the cloud. Doesn’t that mean it is backed up and secured?
The provider secures the platform. You still own what is inside it. Microsoft’s shared responsibility documentation puts customer data, configurations and settings, and identities and users on the customer side of the line for software-as-a-service, which includes Microsoft 365, and says you always retain responsibility for data, endpoints, accounts and access management no matter the deployment type. So a volunteer who deletes a year of records, a compromised admin account that empties a mailbox, or a retention window that quietly expires all land on the customer side of that line. Native recovery in Microsoft 365 is limited and time-boxed, so treat backup and retention as something you own rather than something the platform handles for you. Ask your church management system and your giving platform the same question, and get the answer in writing.
Microsoft used to give us free licenses. What changed?
Microsoft discontinued the Microsoft 365 Business Premium and Office 365 E1 nonprofit grants at each organization’s next renewal on or after July 1, 2025. What remains is up to 300 granted licenses of Microsoft 365 Business Basic, plus discounts of up to 75 percent on paid nonprofit offers including Business Premium. Business Basic is a lighter plan, so some organizations dropped down at renewal and lost security features without anyone flagging it internally. Check which licenses your tenant is on right now and what each one actually includes.
What should we do first if we think someone got into our email or our giving account?
Do not delete anything and do not wipe the machine. If money moved, call the bank first, because the odds of stopping or recalling a fraudulent transfer drop the longer you wait. Reset passwords and revoke active sessions from a device you know is clean, not the one you suspect. Preserve mailbox rules, sign-in records and audit logs before they age out, since those are what tell you what was actually taken. Ohio’s 45-day notification clock runs from the day you discover the breach or the day someone else tells you about it, not from the day you finish investigating, so a call from your bank or your giving platform can start it. Law enforcement can ask you to delay notice; wanting to finish your own investigation first is not a reason to. Whether the clock runs at all depends on whether the exposure creates a material risk of identity theft or fraud, and on whether one of the exemptions in ORC 1349.19 reaches your organization. If you handle protected health information for someone else, you may also owe that covered entity notice within 60 days under 45 CFR 164.410. Get counsel involved before you send anything to donors or members.