NYDFS Cybersecurity Risk Assessment

NYDFS 23 NYCRR § 500.9 requires you to run a periodic cybersecurity risk assessment of your information systems that is strong enough to drive the design and ongoing updates of your NYDFS cybersecurity program. You must refresh it when changes to systems, nonpublic information, or business operations make prior conclusions stale. (23 NYCRR Part 500)

Key takeaways:

• Your risk assessment must be decision-grade: it should directly determine cybersecurity program priorities and control requirements. (23 NYCRR Part 500)
• Treat it as a living process, not an annual document; update it when your environment changes. (23 NYCRR Part 500)
• Document your risk evaluation criteria and risk categorization method so an examiner can see how you reached “material risk” conclusions. (23 NYCRR Part 500)

A NYDFS cybersecurity risk assessment is the backbone of your Part 500 compliance story because it is the mechanism NYDFS expects you to use to justify why your cybersecurity program is designed the way it is. If your policies, technical controls, third-party requirements, monitoring, incident response, and investments are not traceable back to assessed risks, exams tend to stall on “show me your basis” questions.

Operationally, treat § 500.9 as a repeatable governance process with three outputs: (1) a current view of information systems and nonpublic information in scope, (2) a defensible method for evaluating and categorizing cybersecurity risks (with documented criteria), and (3) a set of prioritized actions that feed your cybersecurity program roadmap. The 2023 amendments strengthened expectations around documenting the criteria used to evaluate and categorize risks and, for certain organizations, conducting the assessment at least annually. (23 NYCRR Part 500)

This page gives you requirement-level implementation guidance: who needs to comply, what “periodic” should mean in practice, how to run the assessment step-by-step, what evidence to retain, and the exam questions that tend to create rework.

Regulatory text

Requirement (operator view):
“Each covered entity shall conduct a periodic risk assessment of the covered entity's information systems, sufficient to inform the design of the cybersecurity program. The risk assessment shall be updated as reasonably necessary to address changes to the covered entity's information systems, nonpublic information, or business operations.” (23 NYCRR Part 500)

What that means for you:

• You must perform a risk assessment that is about your information systems (not a generic enterprise risk register) and that is strong enough to drive cybersecurity program design. (23 NYCRR Part 500)
• “Periodic” is not defined in the excerpt; the amendments summary indicates strengthened expectations and that Class A companies must conduct risk assessments at least annually, while other covered entities must do so “as reasonably necessary.” (23 NYCRR Part 500)
• You must update the assessment when meaningful change occurs in systems, nonpublic information, or business operations (examples below). (23 NYCRR Part 500)

Plain-English interpretation (what an examiner is looking for)

An examiner is trying to confirm three things:

1. You know what you run and what data you hold. Your inventory and data flows show where nonpublic information exists and which systems process it. (23 NYCRR Part 500)
2. You have a consistent way to judge cyber risk. You can explain the criteria for severity/likelihood (or your chosen method) and how you categorize risks, including what you consider “material.” (23 NYCRR Part 500)
3. Your cybersecurity program is a consequence of the assessment. Your control design, roadmap, exceptions, and compensating controls map back to assessed risks, threats, and vulnerabilities in your environment. (23 NYCRR Part 500)

Who it applies to (entity and operational context)

Covered entities: Organizations subject to NYDFS Cybersecurity Regulation (23 NYCRR Part 500), including NYDFS-regulated financial institutions and state-registered advisers as noted in the applicability summary. (23 NYCRR Part 500)

Operational scope:

• Information systems supporting NYDFS-regulated business and nonpublic information (wherever stored, processed, or transmitted). (23 NYCRR Part 500)
• Third parties matter because they often host systems or handle nonpublic information; your risk assessment should explicitly include third-party relationships as part of your environment and business operations. (23 NYCRR Part 500)

What you actually need to do (step-by-step)

Below is a practical sequence that produces exam-ready outputs.

1) Set the method and document the criteria first

Pick a risk assessment approach your team can execute consistently (example: qualitative likelihood/impact, or a control-based gap assessment that produces risk ratings). Then write down the criteria for:

• Risk rating scale definitions (what “high” means for impact and likelihood in your context). (23 NYCRR Part 500)
• How you categorize risks (by domain: identity, endpoint, network, cloud, application, data, third-party, resilience). (23 NYCRR Part 500)
• What triggers “material risk” for escalation to senior management and program prioritization. (23 NYCRR Part 500)

Deliverable: “Risk Assessment Methodology & Criteria” document, version-controlled. (23 NYCRR Part 500)

2) Define scope: systems, data, and business processes

Build a scoped inventory that answers:

• What are your information systems (on-prem, cloud, SaaS, endpoints, core applications)? (23 NYCRR Part 500)
• Where is nonpublic information processed/stored/transmitted (systems + data flows)? (23 NYCRR Part 500)
• Which business operations are in scope (customer-facing, trading, underwriting, advisory, claims, payments), and what has changed since the last assessment? (23 NYCRR Part 500)

Tip: Don’t wait for perfect CMDB maturity. Use a pragmatic “system-of-record” approach: start with authoritative sources you already have (asset tooling exports, cloud account inventories, SaaS list from SSO, procurement list for third parties), then reconcile.

Deliverables: System inventory, data inventory, and high-level data flow diagrams for nonpublic information. (23 NYCRR Part 500)

3) Identify threats and vulnerabilities tied to your environment

For each key system/data set:

• Identify plausible threats (credential theft, ransomware, insider misuse, third-party compromise, misconfiguration, DDoS, data exfiltration). (23 NYCRR Part 500)
• Identify vulnerabilities and exposures (missing MFA, weak privileged access, unsupported systems, insecure internet exposure, weak logging, untested recovery, insecure vendor connectivity). (23 NYCRR Part 500)

Keep this grounded in what you can evidence. If you cannot support a claim with artifacts, phrase it as an assumption and assign validation actions.

Deliverable: Risk register entries that connect system + data + threat + vulnerability. (23 NYCRR Part 500)

4) Assess inherent risk and control effectiveness

Rate:

• Inherent risk before controls, based on your documented criteria. (23 NYCRR Part 500)
• Control effectiveness for the relevant controls (identity, network security, secure configuration, vulnerability management, backups, monitoring, incident response, third-party controls). (23 NYCRR Part 500)
• Residual risk after controls, and whether it is acceptable, needs remediation, or needs a compensating control and exception. (23 NYCRR Part 500)

Practical control mapping: Many teams map to NIST CSF or ISO 27001 control families to structure coverage, then convert gaps into NYDFS program requirements and work items. Keep the mapping simple: examiners want traceability, not a 200-control spreadsheet.

Deliverable: Completed risk ratings with clear rationale fields and references to evidence. (23 NYCRR Part 500)

5) Produce an action plan that feeds the cybersecurity program

A risk assessment that stops at scoring fails the “sufficient to inform the design” test. Convert findings into:

• Prioritized remediation plan (owners, due dates, dependencies). (23 NYCRR Part 500)
• Program design decisions (which controls must be strengthened; where to add monitoring; third-party contract requirements). (23 NYCRR Part 500)
• Risk acceptance decisions with approvals and compensating controls where remediation is not immediate. (23 NYCRR Part 500)

Deliverable: Cybersecurity roadmap tied to top risks, plus documented risk acceptances. (23 NYCRR Part 500)

6) Define “as reasonably necessary” update triggers and run them

Create triggers that force an interim update, such as:

• New core system, cloud migration, major SaaS adoption, network redesign. (23 NYCRR Part 500)
• New nonpublic information types, new data sharing channels, new integrations/APIs. (23 NYCRR Part 500)
• M&A, new product lines, expansion into new geographies, outsourcing of key operations to a third party. (23 NYCRR Part 500)

Deliverable: Risk assessment refresh log (what changed, what was re-scored, what decisions changed). (23 NYCRR Part 500)

7) Operationalize ownership and cadence

Assign:

• Process owner (often CISO or GRC lead) and accountable executive (CCO/CIO/CISO depending on structure).
• Contributors (IT, security engineering, application owners, data owners, third-party risk, privacy, business unit leaders). (23 NYCRR Part 500)
• A repeatable calendar: at minimum, a periodic cycle plus event-driven updates; if you are a Class A company, align to the “at least annually” expectation in the amendments summary. (23 NYCRR Part 500)

Tooling note: Daydream can help by centralizing inventories, third-party relationships, evidence, and risk decisions in one workflow so your risk assessment outputs stay traceable to artifacts and updates don’t become a quarterly fire drill.

Required evidence and artifacts to retain

Maintain these in an audit-ready repository with version control:

• Risk assessment report (scope, approach, key risks, conclusions). (23 NYCRR Part 500)
• Risk assessment methodology and documented criteria for evaluation and categorization. (23 NYCRR Part 500)
• System inventory and data inventory for nonpublic information. (23 NYCRR Part 500)
• Risk register with inherent/residual risk, rationale, and owners. (23 NYCRR Part 500)
• Evidence pack supporting ratings (selected examples: MFA coverage exports, vulnerability scan summaries, logging/SIEM coverage notes, backup and recovery test results, IR tabletop records, third-party due diligence outputs). (23 NYCRR Part 500)
• Change-trigger refresh log and approvals for risk acceptance/exception decisions. (23 NYCRR Part 500)
• Mapping from top risks to cybersecurity program initiatives (roadmap, project tickets, milestones). (23 NYCRR Part 500)

Common exam/audit questions and hangups

Expect these questions, and pre-build the answers:

1. “Show me how this risk assessment informed your cybersecurity program.” Bring a crosswalk: top risks → control gaps → funded initiatives → current status. (23 NYCRR Part 500)
2. “What changed since last time, and how did you update the assessment?” Provide your triggers and refresh log. (23 NYCRR Part 500)
3. “How do you define and categorize cybersecurity risk?” Provide the criteria document and a few examples of consistent scoring. (23 NYCRR Part 500)
4. “How did you include nonpublic information and third parties?” Show data inventory, key third parties, and how third-party risks were scored and acted on. (23 NYCRR Part 500)

Frequent implementation mistakes (and how to avoid them)

• Mistake: treating the risk assessment as a narrative PDF with no traceability.
  Fix: maintain a structured risk register with evidence links and clear decision outcomes. (23 NYCRR Part 500)

• Mistake: no documented scoring criteria, so ratings look arbitrary.
  Fix: publish criteria, train assessors, and require rationale fields for each rating. (23 NYCRR Part 500)

• Mistake: doing it annually even when major changes happen mid-cycle.
  Fix: formalize change triggers and require interim refreshes after qualifying events. (23 NYCRR Part 500)

• Mistake: excluding third parties because “TPRM owns that.”
  Fix: treat third-party dependence as part of business operations and systems scope; pull in TPRM outputs as inputs to your risk assessment. (23 NYCRR Part 500)

• Mistake: output does not drive action.
  Fix: require every high residual risk to have one of three outcomes: remediation plan, compensating controls, or documented risk acceptance. (23 NYCRR Part 500)

Enforcement context and risk implications

No public enforcement cases were provided in the approved source catalog for this page, so this guidance avoids case-specific claims.

Practically, weak risk assessment hygiene increases the chance that NYDFS views your cybersecurity program as not risk-based. That creates second-order risk: program gaps persist, exceptions are undocumented, and changes (cloud migrations, new third parties, new data uses) introduce exposure faster than controls adapt. Tie your risk assessment outputs to governance artifacts so you can demonstrate control of the process during an exam. (23 NYCRR Part 500)

Practical execution plan (30/60/90)

Numeric timelines require source-backed citations; instead, use phase-based execution you can start immediately.

Immediate (stabilize the requirement)

• Confirm covered entity scope and accountable owner for § 500.9. (23 NYCRR Part 500)
• Publish risk assessment methodology and scoring/categorization criteria. (23 NYCRR Part 500)
• Build an initial scoped system and nonpublic information inventory from existing sources. (23 NYCRR Part 500)

Near-term (run the assessment end-to-end)

• Hold working sessions with system owners, security, and third-party risk to identify threats/vulnerabilities and rate inherent/residual risk. (23 NYCRR Part 500)
• Produce the risk assessment report and risk register with evidence links. (23 NYCRR Part 500)
• Convert top risks into a prioritized remediation roadmap that explicitly “informs the design” of the cybersecurity program. (23 NYCRR Part 500)

Ongoing (keep it current and exam-ready)

• Implement change triggers and a refresh log (systems, data, business operations changes). (23 NYCRR Part 500)
• Operationalize risk acceptance and exception governance with documented approvals. (23 NYCRR Part 500)
• Use a system such as Daydream to keep inventories, evidence, third-party risk inputs, and risk decisions connected so updates do not turn into a rebuild.

Frequently Asked Questions

What does “periodic” mean for NYDFS cybersecurity risk assessments?

The regulation requires a periodic assessment and updates as reasonably necessary when conditions change. The amendments summary indicates strengthened expectations and that Class A companies must conduct assessments at least annually. (23 NYCRR Part 500)

Do I need a separate risk assessment for NYDFS, or can I reuse an enterprise risk assessment?

You can reuse components, but § 500.9 is specifically about cybersecurity risk to information systems and nonpublic information and must be sufficient to inform the cybersecurity program design. If your enterprise assessment does not reach system/data/control detail, it usually needs a cybersecurity-specific layer. (23 NYCRR Part 500)

What evidence proves the assessment “informed the design” of the cybersecurity program?

Keep a traceable chain from assessed risks to program decisions: control requirements, project roadmap, and documented risk acceptances. Examiners typically want to see the linkage, not just the final report. (23 NYCRR Part 500)

How do third parties fit into the NYDFS risk assessment requirement?

Include third-party-provided systems and third parties that access or process nonpublic information as part of your environment and business operations. Bring third-party due diligence outputs into your risk register and reflect resulting control requirements in contracts and oversight plans. (23 NYCRR Part 500)

What triggers an “as reasonably necessary” update?

Treat significant system changes, new or expanded nonpublic information processing, and business operation changes (such as outsourcing or major integrations) as triggers. Document the trigger, what you re-scored, and what program decisions changed. (23 NYCRR Part 500)

How detailed does the risk categorization criteria need to be?

Detailed enough that a second assessor would score the same scenario similarly, using your written definitions and thresholds. If your categories and criteria cannot be applied consistently, your results will look subjective in an exam. (23 NYCRR Part 500)