Cyber Insurance Prep: What to Gather Before Applying

Carriers increasingly want evidence that core protections are operating in the real world—especially multi-factor authentication, endpoint detection and response, and backups that have actually been restored and tested—and New York’s SHIELD Act supplies the regulatory baseline underneath those questions.

I have watched too many organizations treat the application as a procurement task to hand to a broker at the last minute. That approach creates unnecessary legislative friction: the executive director is chasing screenshots, the IT consultant is asked whether backups exist but not whether they work, and a board treasurer discovers that the organization cannot clearly say where donor, employee, client, volunteer, and program data lives. The more useful approach is to treat nonprofit cyber insurance application prep as a compact governance project. Done well, it gives the carrier a coherent risk picture, gives leadership a clearer operating map, and leaves the organization better prepared if an incident ever reaches the Attorney General’s office.

The practical question is not, “Can we buy a policy?” It is, “Can we show that the controls we say we have are enforced, documented, and proportionate to the private information entrusted to us?”

Start with the controls insurers expect to see

The current nyc nonprofit cyber insurance requirements landscape begins with a hard truth: a policy application will often expose the distance between an organization’s informal habits and its actual security posture. A small arts organization, a neighborhood food pantry, and a citywide human-services provider will not have identical technology budgets or data exposure. But each may hold private information of New York residents, and each may rely on email, cloud software, remote staff access, and third-party platforms that create a path for compromise.

Before approaching a broker or carrier, I recommend having one responsible internal owner—often the executive director, operations lead, finance director, or technology manager—assemble answers and evidence for the controls below. This is not an invitation to burden one person with every technical decision. It is a way to make sure someone can coordinate the answers across staff, vendors, and board leadership.

1. Multi-factor authentication, enforced rather than merely available. Insurers commonly expect MFA on organizational email, remote access tools, virtual private networks, and administrator accounts. “Our platform offers MFA” is not the same as “MFA is turned on for every account that can access organization systems.” Confirm the policy, the enrollment status, exceptions, and the person who reviews exceptions. Email deserves special attention because a compromised mailbox can expose records, impersonate executives, redirect payments, and reset passwords across multiple systems.

2. Endpoint Detection and Response on managed devices. Basic antivirus is increasingly not enough for underwriting. EDR gives an organization more visibility into suspicious activity on laptops and desktops and, depending on the service arrangement, may provide monitoring or response support. The application discussion should identify which endpoints are covered, how unmanaged or personally owned devices are treated, who receives alerts, and whether the technology vendor has a documented role during an incident.

3. Off-site backups that can be restored. A backup is not a recovery plan just because files are copied somewhere else. Carriers commonly look for secure, off-site backups and evidence that restoration has been tested. Ask a plain operational question: if a ransomware event locked the shared drive, cloud tenant, or case-management system on a Tuesday morning, can the organization restore its essential records, and how would staff know the restored records are complete? A successful test should be recorded with the date, the system restored, the result, and any corrective action.

4. Administrative access that is limited and reviewable. Organizations often accumulate former staff accounts, shared administrator credentials, and vendor access that nobody has revisited for years. A current list of administrators, a process for promptly disabling departing employees’ access, and a periodic review of privileged accounts help answer underwriting questions without improvisation.

5. A credible process for software updates and vendor oversight. No nonprofit can patch every system instantly, particularly where legacy line-of-business software is involved. But an organization should be able to explain who receives security notices, how high-risk updates are prioritized, and how critical vendors protect the data they host. That explanation is more persuasive than a generic assurance that “our IT person handles it.”

Cyber insurance is not a substitute for operational discipline; it is one part of the financial recovery plan that becomes meaningful only when the organization can demonstrate how it protects the people whose data it holds.

The evidence does not need to be theatrical. Screenshots of enforced MFA settings, a device-management report, a backup restoration log, a short access-review record, and a contract or service description from the managed IT provider may be far more useful than a polished but unsupported narrative.

Build one evidence folder before the application arrives

The most efficient organizations keep a restricted “cyber insurance readiness” folder, with access limited to the people who genuinely need it. Its purpose is not to create a new filing burden. It is to stop the same facts from being reconstructed from scratch every renewal cycle, every audit request, and every serious incident.

A practical folder usually includes:

• a current inventory of systems that store or process private information;
• a list of key vendors, including email, file storage, payroll, fundraising, payment processing, case management, and managed IT;
• proof that MFA is enforced for email, remote access, VPNs, and administrative accounts;
• an endpoint inventory and documentation of EDR coverage;
• backup configuration details and restoration-test records;
• an account offboarding and privileged-access review process;
• the written information security program and its most recent review date;
• the organization’s risk assessment and any remediation priorities;
• the incident response plan, emergency contacts, and outside counsel or forensic vendor details if already designated;
• board minutes or committee records showing that cybersecurity has reached the appropriate governance level.

This packet should not contain passwords, recovery codes, or broadly shareable administrator credentials. The goal is evidence and ownership, not a security risk disguised as documentation.

The SHIELD Act is the floor, not a separate compliance track

New York’s SHIELD Act applies to entities, including nonprofits, that own or license private information of New York residents. The law requires reasonable administrative, technical, and physical safeguards. For many organizations, that phrase sounds broad enough to be unhelpful; in practice, it means the organization needs to connect its safeguards to the kind of information it handles and to the foreseeable risks surrounding that information.

The overlap with insurance underwriting is substantial. A carrier wants to know whether a ransomware attack, business-email compromise, lost laptop, or vendor breach could create a significant financial loss. The SHIELD Act asks whether the organization has reasonable safeguards to prevent and respond to a compromise involving private information. Both inquiries lead back to the same operating questions: What data do we have? Who can access it? What defenses are active? What happens when something goes wrong?

The definition of private information reaches beyond the combinations many organizations traditionally associate with identity theft. It can include biometric information; an email address combined with a password or security question and answer; and certain financial account numbers where access remains possible even without a security code. A nonprofit that maintains donor payment information, client intake files, employee records, volunteer applications, or credentials for shared services should not assume it has a light data footprint simply because it does not operate like a bank or hospital.

A data inventory is therefore the first substantive document in a cybersecurity risk assessment for an NYC charity. It does not need to begin as a sophisticated data-governance platform. A carefully maintained spreadsheet can do the work if it identifies:

I encourage leaders to make this inventory usable rather than encyclopedic. Begin with the systems that would create the most disruption or harm if unavailable or exposed. Then identify the data owner inside the organization, the technology owner or vendor, the approximate number of people whose information may be involved, and the location of the relevant contract or service agreement.

That exercise often surfaces an uncomfortable but productive finding: data is retained because no one has decided when it should be deleted. Retention is a risk-management question, not only an IT question. Records needed for program integrity, audits, grants, and legal obligations must be preserved appropriately; records that no longer serve a defensible purpose should not quietly expand the organization’s exposure year after year.

Write the WISP as an operating document, not a binder artifact

The written information security program, usually called a WISP, is one of the clearest links between nonprofit governance and cyber insurance readiness. Under the SHIELD Act, safeguards should be reasonable in light of the organization’s size, the nature and scope of its activities, the sensitivity of the information it handles, and the cost and availability of security tools. That is not a demand that every small organization reproduce the security department of a major financial institution. It is a demand for conscious, documented choices.

A useful WISP translates that standard into assignments people can follow on an ordinary workday. It should identify who is responsible for the program, what information is covered, how risks are assessed, which core safeguards are required, how staff are trained, how vendors are evaluated, and how the organization responds to suspected incidents.

For nonprofit leadership teams, I would make sure the document answers these questions in plain language:

• Who has authority to make security decisions and to activate the incident response process?
• Which data categories create the highest risk for our community stakeholders if exposed, altered, or unavailable?
• Which staff roles require elevated access, and how are those privileges reviewed?
• Where is MFA mandatory, and who verifies that it remains enforced?
• What is the organization’s minimum standard for device protection, encryption, EDR, and software updates?
• How are vendors selected when they store donor, payroll, client, or staff information?
• How do staff report a suspicious email, a lost device, a mistaken disclosure, or a possible account takeover?
• What records are kept to show training, testing, access reviews, backups, and security decisions?
• When is the WISP reviewed, and which board committee or leadership body receives the findings?

Encryption is one area where organizations should distinguish between a technical capability and a working practice. AES-256 is a common standard for data at rest, but an application answer should reflect the actual configuration of the relevant system, not an assumption based on a vendor’s marketing language. Similarly, a cloud vendor’s security certifications do not automatically establish that the nonprofit has configured user access, retention, sharing permissions, and administrator controls responsibly.

The WISP should also describe physical safeguards in proportion to the organization’s operations. Locked file storage, controlled access to offices, secure disposal of printed records, and procedures for laptops used in the field can matter just as much as a software setting, particularly for organizations where service delivery happens across multiple sites, homes, schools, shelters, or public spaces.

A short WISP that names real systems, real owners, and real response steps will serve a nonprofit better than a forty-page policy copied from an institution with an entirely different risk profile.

Prepare for breach response before an insurer asks the question

The SHIELD Act’s breach standard covers unauthorized access to private information, not only unauthorized acquisition. That distinction matters. An organization does not need proof that files were downloaded or sold before it takes a possible intrusion seriously. If an unauthorized person gained access to private information, the organization may need legal, technical, and communications guidance to determine its notification duties.

For an incident affecting 500 or more New York residents, notifications are required to the New York Attorney General, the Department of State, and the Division of State Police. When more than 5,000 residents are affected, consumer reporting agencies must also be notified. These thresholds should not be read as a reason to delay response to a smaller event; they simply identify additional reporting obligations at larger scale.

The Attorney General can bring civil actions for failures to provide required breach notifications. The potential penalties are the greater of $5,000 or up to $20 per instance of failed notification, capped at $250,000 per breach. But the financial figure is only one part of the nonprofit risk. A poorly managed incident can interrupt services, strain funder relationships, expose already vulnerable clients to harm, and consume leadership capacity at exactly the moment the organization should be delivering on its mission.

The Bureau of Internet and Technology may examine four central artifacts following a breach notification:

1. The submitted breach notification. It should be accurate, timely, and consistent with the organization’s actual understanding of the event.

2. The WISP. This is where the organization shows that security was addressed as a managed responsibility rather than an afterthought.

3. The risk assessment connecting safeguards to the sensitivity of the information. A generic policy will not explain why the organization chose particular controls for its particular data environment.

4. Incident-response evidence. This can include internal reports, decision logs, technical findings, communications records, and documentation of containment and recovery actions.

That is why an incident response plan should be rehearsed at least conceptually before a crisis. The plan does not need to predict every form of attack. It needs to answer who makes the first call, how the organization preserves evidence, when it contacts its insurer, how it brings in technical support, how it protects service continuity, and who is authorized to speak externally.

For a mission-driven organization, I would include program leadership in this planning, not only finance and technology. If a system goes offline, program teams know which services cannot pause, which clients may need alternate contact methods, and what information is too sensitive to discuss through ordinary email. Their perspective is part of risk management, not a post-incident afterthought.

Small nonprofit status changes the scale of safeguards, not the responsibility

The SHIELD Act recognizes that a smaller organization cannot be expected to maintain the same safeguards as a large enterprise. An organization may fall within the Act’s small-business provision if it has fewer than 50 employees, has had less than $3 million in gross annual revenue in each of the last three fiscal years, or has less than $5 million in year-end total assets.

This is a calibration provision, not a complete exemption. Smaller nonprofits still need reasonable administrative, technical, and physical safeguards. The practical benefit is that leaders can design a proportionate program rather than assume compliance requires an expensive, enterprise-level technology stack.

For example, a 12-person community organization may not need a dedicated internal security operations center. It may, however, need MFA across email and administrative accounts, managed EDR through an IT provider, secure off-site backups with restoration testing, a basic data inventory, clear offboarding steps, staff phishing awareness, and a WISP that identifies who is accountable. Those are achievable controls when they are sequenced thoughtfully and supported by the board.

The application itself is an opportunity to explain the organization’s structure honestly. Do not overstate capabilities because a policy form seems to reward a “yes.” If MFA is fully enforced for email but not yet for one legacy system, say so through the broker and describe the remediation timeline. If backups exist but have not been restore-tested, schedule the test before submission where possible. An inaccurate answer can become much more consequential after a claim than a candid, well-documented account of a control that is still being strengthened.

A practical 30-day readiness route

Many NYC nonprofits do not need a yearlong transformation before seeking coverage. They need a disciplined first month that separates urgent controls from longer-term improvements and gives the broker a reliable packet to work with.

Week one: assign ownership and map the exposure. Convene operations, finance, program, and technology contacts. Identify the systems that hold private information, the staff and vendors with administrative access, and the most consequential interruption scenarios. Create the initial evidence folder.

Week two: close the baseline control gaps. Enforce MFA on email, remote access, VPNs, and administrator accounts. Confirm EDR deployment. Review backup locations, immutability or protection features where available, and the scheduled restoration test. Remove stale accounts and confirm how offboarding occurs.

Week three: turn practices into documentation. Draft or update the WISP, complete a concise risk assessment, collect vendor information, and write the incident response call tree. Make sure the documents name responsible roles, not just broad departments that may not exist in a small organization.

Week four: test and brief leadership. Conduct a backup restoration test. Walk through a tabletop scenario involving a compromised email account or ransomware notice. Bring a short briefing to the board or relevant committee: current risks, completed controls, outstanding items, insurance application status, and the decision points that require governance support.

This route will not eliminate cyber risk, and no responsible broker or consultant should imply otherwise. It will, however, give an insurer a more credible view of the organization’s readiness and give the nonprofit a framework it can sustain after the policy is bound.

The strongest nonprofit cyber liability checklist is ultimately not the one with the most boxes. It is the one that connects technical controls, leadership accountability, staff habits, vendor relationships, and the real needs of the communities the organization serves. I would begin with the evidence carriers expect, anchor it in the SHIELD Act’s reasonable-safeguards standard, and then use the application process to build a recurring board-and-management rhythm: review the risks, fund the priority fixes, test the response, and document the decisions. That is how cyber insurance becomes part of responsible stewardship rather than another anxious administrative scramble.