New York Just Published Risk Assessment Guidance. Nonprofits Should Read It.
On September 10, 2026, New York’s Department of Financial Services (DFS) published detailed risk assessment guidance spelling out exactly how regulated banks and insurers should conduct cybersecurity risk assessments — governance, methodology, scope, documentation, the works.
If you run a nonprofit or association, your first instinct might be to skip right past this one. DFS regulates financial institutions, not charities, and this guidance creates no legal obligation for you at all.
Here’s why it’s worth reading anyway: a documented risk assessment — done well — is exactly what demonstrates “reasonable cybersecurity,” a phrase that already shows up in at least two rules nonprofits actually do answer to. DFS didn’t coin that phrase or write this guidance with nonprofits in mind, but the process it lays out is one of the clearest free explanations any regulator has published this year of how to get there.
The Law You’re Actually Subject To
Most nonprofits aren’t “Covered Entities” under DFS’s Part 500 cybersecurity rule. But nearly every nonprofit that touches New York — through donors, employees, members, volunteers, or program participants — is subject to a different New York law: the SHIELD Act (Stop Hacks and Improve Electronic Data Security Act).
The SHIELD Act applies to any organization, nonprofit or not, that holds computerized private information about a New York resident, regardless of where the organization itself is located. It requires “reasonable administrative, technical and physical safeguards” appropriate to the organization’s size, complexity, and the sensitivity of the data it handles. There’s no size floor that exempts you entirely — smaller organizations get a scaled-down version of the requirement, not a pass. Penalties for failing to maintain reasonable safeguards can run up to $5,000 per violation, on top of separate penalties for failing to notify affected individuals after a breach.
The problem: “reasonable safeguards” is a legal standard, not a checklist. Regulators and courts look for evidence that an organization actually identified its risks, weighed them, and built its controls around what it found. In other words, they look for a documented risk assessment.
What Does “Reasonable” Actually Mean Under SHIELD?
The statute doesn’t leave “reasonable safeguards” entirely to interpretation. An organization is deemed compliant if its data security program includes safeguards across three categories:
Administrative safeguards — designating someone to coordinate the program, identifying foreseeable internal and external risks, assessing whether current safeguards are sufficient to control those risks, training employees on the program’s practices, and vetting vendors’ security practices contractually before giving them access to your data.
Technical safeguards — assessing risk in your network and software design, and in how information is processed, transmitted, and stored; having a way to detect, prevent, and respond to attacks or system failures; and regularly testing and monitoring whether your controls are actually working.
Physical safeguards — assessing risks around how private information is stored and disposed of, protecting against unauthorized physical access during collection, transport, or destruction of data, and disposing of private information within a reasonable timeframe once it’s no longer needed.
None of this requires enterprise-grade tooling. A 12-person nonprofit satisfies “reasonable” differently than a national association with a 40-person IT department — but both need to be able to point to something in each category.
A Second Standard: What does “Reasonable” Mean If You Take Federal Funds?
SHIELD isn’t the only place “reasonable cybersecurity” shows up in the rules nonprofits actually operate under. If your organization receives federal grants or contracts — directly or as a subrecipient — the Office of Management and Budget’s updated Guidance for Federal Financial Assistance now requires reasonable cybersecurity internal controls too, under 2 CFR § 200.303. Like SHIELD, it deliberately avoids naming one required framework; unlike SHIELD, it extends beyond personally identifiable information to any data a federal agency designates as sensitive — which broadens the stakes for grant-funded programs holding client, participant, or research data that wouldn’t otherwise trigger a state privacy law.
Failing to meet this standard doesn’t just create breach exposure — it can put a recipient’s eligibility for federal funding itself at risk.
Here’s the important nuance: not every nonprofit is on the hook for all of this. SHIELD applies only if you hold private information on New York residents. OMB’s 2 CFR 200.303 applies only if you receive federal grant or contract dollars. And the DFS guidance itself imposes no legal obligation on nonprofits at all — it only binds DFS-regulated financial entities, so for everyone else it’s simply a useful process to borrow, not a rule you’re bound by. Depending on your data and funding sources, you could be legally subject to one of these standards, both, or neither.
What ties them together: whichever ones actually apply to you — and even if none legally do — the same underlying risk assessment process, the one DFS just laid out, is how you’d demonstrate “reasonable” if anyone ever asked.
A practical way to operationalize this: GRF’s own Cybersecurity Pathway breaks “reasonable” down into four steps that map cleanly onto everything above:
- Establish your baseline — a risk assessment scoped to your size, complexity, and data sensitivity
- Build the program — reference a recognized framework like NIST CSF or ISO 27001, classify your data, write an incident response plan, and vet third-party vendors contractually
- Train your people — ongoing awareness training, since most breaches start with a person, not a firewall
- Keep it current — continuous monitoring, patching, and periodic external audits of your top risk areas
Run through those four steps once and document what you find and what you did about it, and you’ve built the evidentiary trail that satisfies SHIELD (if it applies to you), meets OMB’s expectation (if it applies to you), and follows the process DFS describes (whether or not you’re bound by it) — all from the same underlying work.
What the New DFS Guidance Adds: A Process for Getting There
Stripped of its bank-and-insurer framing, the September 2026 guidance boils down to five practices that translate directly to any nonprofit or association, and that fill in the “how” behind the Pathway above:
- Put someone in charge, and report up to governance — not just to IT. SHIELD expects you to designate someone to coordinate your data security program. DFS goes further, requiring that material cybersecurity risks be reported to the organization’s Senior Governing Body — not absorbed and resolved quietly inside IT. That’s not a DFS quirk; it’s the same principle NIST built into the Cybersecurity Framework 2.0 in February 2024, when it added a sixth core function, Govern, and placed it at the center of the framework rather than alongside the other five. Categories that used to sit under “Identify” — business context, risk management strategy, supply chain risk — moved into Govern specifically to stop cybersecurity from being treated as a technical problem the IT department solves on its own, and to start treating it as an enterprise risk the board oversees, funds, and asks questions about.
- Use a repeatable method, not a one-time exercise. A risk assessment that happens once, gets filed, and never gets revisited isn’t a risk assessment — it’s a snapshot of a moment that’s already passed. DFS calls for a defined methodology that scores likelihood and impact consistently, so you can compare results year over year and actually see whether your risk posture is improving.
- Cover more than your servers. DFS is explicit that a risk assessment needs to account for hardware, software, and processes, people, and third-party vendors — plus, notably, emerging technology and “concentration risk,” where too many critical functions depend on the same vendor or platform. For a nonprofit, that means your AMS, your donor database vendor, your outsourced IT provider, and increasingly, any AI tools staff have started using on their own (more on that below) all belong in scope.
- Write it down and connect the dots. A risk you can’t point to on paper is a risk you can’t defend having addressed. DFS wants a clear trail from “here’s the risk we identified” to “here’s the control we put in place, or here’s why we accepted the risk instead.” This is precisely the kind of documentation that turns “we take security seriously” into evidence a regulator, auditor, or insurer will actually accept.
- Update it when something changes, not just once a year. DFS requires reassessment at least annually and after any material change — a new system, a merger, a new vendor relationship, or a shift in the threat landscape. A staff-driven AI adoption wave counts.
Why This Belongs on Your ERM Agenda, Not Just Your IT Agenda
Notice what points 1 and 4 have in common: identified risks get documented, and material ones get reported to the people responsible for overseeing the organization’s overall risk — not just to whoever manages the servers. That’s the definition of enterprise risk management applied to one specific risk category.
Nonprofits that already run a broader ERM process have an advantage here: cybersecurity risk doesn’t need its own separate reporting structure. It slots into the risk register, heat map, or risk appetite conversation your board is already having about financial, program, and reputational risk — cyber just becomes one more line on that register, scored with the same criteria and reported on the same cadence. Organizations without a broader ERM function tend to let cybersecurity risk live entirely inside IT, which is exactly the pattern DFS is asking regulated entities to move away from, and exactly what NIST restructured its framework to correct.
If your board isn’t currently seeing cybersecurity risk presented alongside your other enterprise risks — with the same likelihood/impact scoring and the same “here’s what we’re doing about it” follow-through — that’s a gap worth closing before it becomes a compliance finding or a breach postmortem.
The AI Wrinkle Nonprofits Can’t Ignore
The most interesting detail in the new DFS guidance is what it says about emerging technology: organizations should specifically consider whether the growing use of artificial intelligence changes their risk profile, and it identifies frontier AI models and evolving threat-actor capabilities as examples of “material changes” that should trigger a fresh look at your risk assessment.
Nonprofits are adopting AI tools for everything from grant writing to donor outreach — often without any formal IT review. If your organization doesn’t have visibility into which AI tools staff are using and what data those tools touch, that’s a gap in your asset inventory, and it’s exactly the kind of gap examiners (and increasingly, insurers issuing cyber policies) are starting to ask about.
Turning This Into Action
You don’t need a DFS-grade compliance program to benefit from this guidance. You need:
- A named person accountable for your data security program (required if SHIELD applies to you), reporting material risks up to the board or a designated committee
- A current inventory of your systems, vendors, and data — including the AI tools your team has quietly started using
- A documented, repeatable way of identifying and rating risks, using criteria consistent with however you already score other enterprise risks
- A record connecting each risk to what you did about it
- A commitment to revisit all of it annually at the least, and sooner if something significant changes
- For federal funding recipients, confirmation that your program also satisfies 2 CFR 200.303’s reasonable-security expectation for award recipients
If that sounds like more structure than your organization has today, you’re far from alone — and it’s a solvable problem, not a five-alarm one.
Where to Go Next
GRF’s Risk & Advisory Services team works with nonprofits and associations on exactly this kind of assessment and on building the broader ERM structure for recording and monitoring cybersecurity risk.
Cybersecurity:
- GRF Cybersecurity Services — including the Cybersecurity Pathway referenced above
- GRF Cybersecurity Risk Assessment and Scorecard — a diagnostic covering 20 risk categories, built specifically for nonprofits and associations
- Checklists for Privacy, IT and Third-Party Risk — practical checklists to self-assess before you bring in outside help
- Community-Based Nonprofit Case Study — a real example of a scorecard-driven risk assessment in action, including how it changed board-level conversations about IT
Enterprise Risk Management:
- Enterprise Risk Management Resources — GRF’s curated ERM hub, including the Top Risks Report and an ERM handbook written for association board members
- Getting Started with Enterprise Risk Management: A Guide for Nonprofits — a full ERM implementation guide with downloadable templates, developed with NC State’s ERM Initiative
- Enterprise Risk Management for Nonprofits & Associations — GRF’s ERM advisory services page
Join us at our Cybersecurity Symposium for Nonprofits!
GRF’s 4th annual Cybersecurity Symposium for Nonprofits is a virtual event on December 8, 2026 from noon to 3pm ET. It provides a practical overview of the latest strategies for improving cybersecurity and operational IT functions at any size organization.
About the Author
Melissa Musser, CPA, CITP, CIA, CISA, is a Partner and Director of Risk & Advisory Services at GRF CPAs & Advisors, where she helps nonprofit organizations and associations build and strengthen their cybersecurity, IT risk, and enterprise risk management programs.
