NYDFS Part 500's First Full Exam Cycle: What Must Your Matured Cybersecurity Program Now Evidence?

For three years, "we are still inside the transitional window" was a defensible answer to a DFS examiner. That answer is gone.

The Second Amendment to 23 NYCRR 500 took effect November 1, 2023. Section 500.22 then staggered compliance dates off that effective date, and the longest of those windows ran two years. The last one closed November 1, 2025. By the time examiners are conducting field work in 2026, every Part 500 obligation is fully in force. There is no tranche left to hide behind.

This is the first exam cycle where the question stops being "are you on track to comply" and becomes "show me the evidence that you do." That is a different posture. A roadmap is not evidence. A policy PDF is not evidence. Evidence is a dated artifact, tied to an obligation, that an examiner can inspect without you assembling it on the spot.

This piece walks through what a matured program has to be able to produce, section by section, with the gotchas that catch teams who treated the transitional period as a planning exercise instead of an operating one.

Why is 2026 the first exam cycle where every NYDFS Part 500 transitional deadline has already passed?

Part 500's transitional periods are not a single grace window. Section 500.22 sets several, each measured from the Second Amendment effective date of November 1, 2023.

The two that matter most for a 2026 exam are the longest ones:

• 18 months (to May 1, 2025) for the new requirements in §500.5(a)(2), §500.7, §500.14(a)(2), and §500.14(b). That covers the expanded vulnerability-scanning language, the rewritten access-privileges section, and the monitoring and training requirements.
• 24 months (to November 1, 2025) for §500.12 and §500.13(a). That is full multi-factor authentication and the documented asset inventory.

Read that second line again, because it is the one teams underestimate. MFA-everywhere and the asset inventory were the last obligations to come due, and they came due barely six months before the mid-2026 exam season. If your program treated those two as "we will get to them when the deadline is closer," the deadline is now behind you and the evidence trail is thin.

The practical consequence: an examiner in 2026 can ask for a full year of operating evidence on the early tranches and a half-year on the last two. A program that switched controls on in October 2025 to beat the clock has almost no operating history to show. That gap is exactly what a first-cycle exam is designed to surface.

What does §500.2 actually require your cybersecurity program to demonstrate to a DFS examiner?

Section 500.2 is the spine. It requires a cybersecurity program based on your risk assessment that performs six core functions: identify and assess risks, protect systems with defensive infrastructure and policies, detect cybersecurity events, respond to mitigate negative effects, recover and restore normal operations, and fulfill applicable regulatory reporting obligations.

Note the phrase "based on the covered entity's risk assessment." This is not decoration. It is the thread an examiner pulls. They will ask to see the risk assessment, then ask how a specific control traces back to a finding in it. If your controls and your risk assessment live in separate documents that never reference each other, you fail that trace even if both documents are excellent on their own.

Section 500.2(e) closes the loop: all documentation and information relevant to the program must be made available to the superintendent upon request. That single clause is the whole evidence argument. "We do this" is not the standard. "Here is the documentation, on request" is.

What a matured program shows here:

1. A current risk assessment that names the risks to your specific information systems and nonpublic information.
2. A control set where each major control maps to a risk the assessment identified.
3. A documentation index so that "upon request" is a query, not a fire drill.

The gotcha: programs that bought a generic framework off the shelf and never tailored it to their own risk assessment. Part 500 does not ask whether you adopted a good framework. It asks whether your program flows from your risk assessment. A copied control library that does not reference your findings reads, to an examiner, as a program that was never actually based on the assessment §500.2(b) requires.

How will examiners test §500.9 risk assessment and §500.4 CISO reporting to the senior governing body?

These two sections are where governance becomes auditable.

Section 500.9 requires a periodic risk assessment, reviewed and updated as reasonably necessary but at a minimum annually, and whenever a business or technology change causes a material change to your cyber risk. It must be carried out under written policies and procedures and documented, and those policies must include criteria for evaluating and categorizing risks and a description of how identified risks will be mitigated or accepted.

The annual-minimum is the easy part to evidence: one assessment per calendar year, dated. The part teams skip is the material-change trigger. If you migrated a core system, acquired a business, or stood up a new customer-facing platform during the year and your risk assessment never moved, an examiner sees a process that does not actually respond to change. The fix is operational: tie a risk-assessment review to your change-management process so a material change produces a dated reassessment artifact, not just a ticket.

Section 500.4 puts the CISO on record with the board. The CISO must report in writing at least annually to the senior governing body on the program, including the confidentiality, integrity and security of systems, the policies and procedures, material risks, the overall effectiveness of the program, material cybersecurity events during the period, and plans for remediating material inadequacies.

And §500.4(d) is the obligation that has teeth in 2026: the senior governing body must exercise oversight of cybersecurity risk management, including having sufficient understanding to do so, regularly receiving and reviewing management reports, and confirming that management has allocated sufficient resources to maintain an effective program.

Here is the evidence sequence examiners will reconstruct:

1. The written CISO report, dated, covering all six §500.4(b) elements.
2. The senior governing body meeting record showing the report was received and reviewed.
3. The minute or resolution where the body confirmed sufficient resources were allocated.

That third artifact is the one most programs cannot produce. A board deck titled "Cybersecurity Update" does not establish that the governing body confirmed resource sufficiency. Capture that confirmation as an explicit, dated record. If it is not written down, under §500.4(d) it did not happen.

After the final tranche, what does full MFA under §500.12 and the §500.13 asset inventory have to show?

These are the two-year-tranche obligations, and they are the ones with the least operating history going into a 2026 exam. Treat them as the highest-scrutiny line items.

§500.12 — MFA everywhere. The amended language is broad. MFA must be used for any individual accessing any information systems of the covered entity. The narrower, privileged-and-remote-only scope only applies if you qualify for the limited exemption under §500.19(a), in which case MFA is required for remote access, remote access to third-party applications holding nonpublic information, and all privileged accounts other than non-interactive service accounts.

This is the single biggest scope change teams get wrong. The old mental model was "MFA on VPN and admin accounts." Under the current rule, that scope is only defensible if you actually hold the §500.19(a) limited exemption. If you do not, "any individual accessing any information systems" means exactly that. Internal applications. On-premise systems. The lot.

If you rely on §500.12(b) compensating controls instead of MFA on a given system, the CISO must approve them in writing, and they must be reviewed at least annually. Examiners will ask for the signed approval and the dated review. An undocumented "we decided MFA was not feasible here" is a finding.

§500.13(a) — the asset inventory. Written policies and procedures must produce and maintain a complete, accurate and documented asset inventory. At a minimum the policies must track, for each asset as applicable: owner, location, classification or sensitivity, support expiration date, and recovery time objectives, plus the frequency required to update and validate the inventory.

The fields teams skip are the last two. Owner, location, and classification show up in most CMDBs. Support expiration date and recovery time objectives rarely do. Those two fields are precisely what make the inventory useful for risk and resilience decisions, which is why the rule names them. An inventory missing them is incomplete on its face, and "complete and accurate" is the literal standard. Audit your inventory schema against all five fields before an examiner does.

Section 500.13 also requires policies for secure periodic disposal of nonpublic information that is no longer necessary for business operations. The inventory and the disposal policy are two halves of the same obligation: you cannot defensibly dispose of what you have not inventoried.

What §500.7 access-privilege, §500.5 vulnerability-management, and §500.15 encryption evidence does a matured program need?

These three sections are the operational core, and each one carries an annual-cadence proof.

§500.7 — access privileges. Based on your risk assessment, you must limit user access to nonpublic information to what the job requires, limit the number and functions of privileged accounts, limit privileged-account use to when it is actually needed, and review all user access privileges periodically but at a minimum annually, removing or disabling access that is no longer necessary. You must also promptly terminate access following departures.

The annual access review is a dated artifact: who reviewed, what was reviewed, what was revoked. The departure-termination requirement is where programs bleed. "Prompt" is tested against your own offboarding records. If your average time-to-deprovision after a termination is measured in weeks, that metric is your finding waiting to be written. Instrument it.

§500.5 — vulnerability management. Under written policies you must conduct penetration testing from both inside and outside your information systems' boundaries by a qualified internal or external party at least annually, run automated scans (plus manual review of systems the scans miss) at a frequency determined by the risk assessment and promptly after material system changes, maintain a monitoring process so you are promptly informed of new vulnerabilities, and timely remediate, prioritizing by the risk each vulnerability poses.

Note the scan frequency is risk-driven, not a fixed number in the rule. That means your evidence has to show the link: the risk assessment sets the cadence, and the scan records match it. The remediation requirement is the one with no fixed clock either, which makes "timely" a judgment an examiner will test against your own SLAs and your actual close-out dates. A backlog of critical vulnerabilities open past your stated SLA is the most common vulnerability-management finding.

§500.15 — encryption. A written policy must require encryption of nonpublic information both in transit over external networks and at rest. Where at-rest encryption is infeasible, you may use effective compensating controls, but only with CISO written approval, and the feasibility and effectiveness must be reviewed by the CISO at least annually.

The pattern repeats: the exception requires a signed, annually-reviewed artifact. If you have legacy systems where data sits unencrypted at rest, the question is not whether that is allowed. It is whether you have the CISO's written infeasibility determination and this year's review. No artifact, no defense.

How do the §500.17 72-hour, 24-hour extortion-payment, and April 15 certification obligations change your evidence trail?

Section 500.17 is the reporting section, and it sets hard clocks. Hard clocks are the easiest obligations for an examiner to score because they are pass or fail against a timestamp.

• 72 hours. You must notify the superintendent electronically no later than 72 hours after determining that a cybersecurity incident has occurred at you, an affiliate, or a third-party service provider. The clock starts at determination, not at the incident. So your evidence has to capture when determination happened. An incident log that records detection but not the determination decision leaves the clock un-anchored, and an examiner reviewing a past incident will ask exactly when the 72 hours started.
• 24 hours, then 30 days, for extortion payments. If you make an extortion payment in connection with a cybersecurity event, you must notify the superintendent within 24 hours of the payment, and within 30 days provide a written description of why payment was necessary, the alternatives considered, and the diligence performed, including OFAC compliance. Bake these two deadlines into your incident-response runbook now, because the 24-hour clock is not a window you can plan for under pressure.
• April 15 certification. Annually, by April 15, you must submit electronically either a written certification of material compliance for the prior calendar year, or a written acknowledgment that you did not materially comply, identifying the deficient sections and providing a remediation timeline. Either submission must be signed by the highest-ranking executive and the CISO.

That dual signature is the change that reshapes the evidence trail. The annual filing is no longer a compliance-team formality. The highest-ranking executive is personally signing an attestation grounded in §500.17(b), which states the certification must be based on data and documentation sufficient to accurately determine and demonstrate material compliance. And you must retain the supporting records for five years.

Here is the operational sequence a matured program runs into April 15:

1. Assemble per-section evidence across the prior calendar year, mapped to each Part 500 requirement.
2. Identify any section where the evidence does not support material compliance.
3. Decide certification versus acknowledgment honestly on that basis.
4. Get the highest-ranking executive and CISO signatures.
5. Preserve the supporting documentation set for five years, indexed by section.

The gotcha is signing a certification your evidence cannot support. An acknowledgment with a credible remediation timeline is a defensible position. A certification that an examiner later contradicts with your own records is the worst outcome in the rule, because now the signed attestation is itself the evidence against you.

What heightened controls must a Class A company evidence that other covered entities do not?

A Class A company is a covered entity with at least $20,000,000 in gross annual revenue in each of the last two fiscal years (counting the entity and its in-state affiliate operations) and either over 2,000 employees averaged over the last two fiscal years, or over $1,000,000,000 in gross annual revenue in each of the last two fiscal years, counting the entity and all affiliates.

First gotcha: the affiliate math. Whether you cross the threshold depends on how affiliates are counted, and the definition only includes affiliates that share information systems, cybersecurity resources, or part of a cybersecurity program with you. If you have not deliberately determined your Class A status, an examiner may determine it for you, and being told you were a Class A company that failed to meet the heightened bar is a bad way to find out.

Class A companies carry two heightened obligations beyond the baseline:

• Independent audits (§500.2(c)). Each Class A company must design and conduct independent audits of its cybersecurity program based on its risk assessment. "Independent" means auditors free to make decisions not influenced by the entity being audited. Evidence is the audit charter, the auditor's independence basis, and the dated audit reports.
• PAM plus password blocking (§500.7(c)). Class A companies must monitor privileged-access activity and implement a privileged access management solution and an automated method of blocking commonly used passwords for all accounts on systems they own or control, and wherever feasible for all other accounts. Where blocking is infeasible, the CISO must approve the infeasibility and compensating controls in writing at least annually.

If you are a Class A company, these are not aspirational. A PAM solution that is procured but not deployed, or a password-blocking capability that covers the directory but not the standalone systems, is a partial control that reads as a gap.

How do you turn 23 NYCRR 500 obligations into a continuously query-able audit pack instead of an annual scramble?

Here is the structural problem with how most programs approach Part 500. The obligations are continuous. The evidence-gathering is annual. So every spring becomes a scramble to reconstruct a year of operating history that should have been captured as it happened.

The fix is to stop treating the audit pack as a project and start treating it as a query. Every Part 500 obligation maps to a control, every control produces evidence, and every piece of evidence carries a date and a section reference. When that mapping exists as structured data instead of a folder of PDFs, "show me your §500.7 access reviews for the last year" is a filter, not a fire drill.

That is the model Aegis GRC is built on. One organizational profile maps your obligations across 245+ regulations across 28 jurisdictions, every obligation traced to a verbatim quote from the source legal text. For Part 500 specifically, each section becomes a set of expectations, each expectation is bound to the evidence that satisfies it, and the April 15 certification stops being an annual reconstruction. The audit pack is a query, not a project.

That is also what a first-cycle exam rewards: not the program that scrambled to switch controls on before the deadline, but the program that can answer, section by section, with dated evidence already in place.

See your NYDFS Part 500 obligations mapped to the evidence each one demands — aegis-grc.com.

FAQ: Part 500 exam-readiness questions CISOs ask

When did all the NYDFS Part 500 Second Amendment deadlines pass? The Second Amendment took effect November 1, 2023. Section 500.22 staggered compliance dates from there. The 18-month tranche (§500.5(a)(2), §500.7, §500.14(a)(2), §500.14(b)) closed May 1, 2025, and the 24-month tranche (§500.12 MFA and §500.13(a) asset inventory) closed November 1, 2025. By the 2026 exam cycle, every window has closed.

Does §500.12 really require MFA on every system? Under §500.12(a), MFA must be used for any individual accessing any information systems of the covered entity. The narrower remote-and-privileged-only scope only applies if you qualify for the limited exemption under §500.19(a). If you do not hold that exemption, MFA-everywhere is the requirement, and any reliance on compensating controls needs the CISO's written approval, reviewed at least annually.

Who has to sign the April 15 certification? Under §500.17(b), the annual certification or acknowledgment must be signed by the covered entity's highest-ranking executive and its CISO. If there is no CISO, it is signed by the highest-ranking executive and the senior officer responsible for the cybersecurity program. You must retain the supporting documentation for five years.

What makes a company a Class A company under Part 500? Per §500.1(d): at least $20,000,000 in gross annual revenue in each of the last two fiscal years, and either over 2,000 employees averaged over the last two fiscal years or over $1,000,000,000 in gross annual revenue in each of the last two fiscal years, counting affiliates that share information systems or cybersecurity resources. Class A companies face heightened requirements including independent audits under §500.2(c) and a privileged access management solution plus automated blocking of commonly used passwords under §500.7(c).

Which asset-inventory fields do teams most often miss under §500.13? Owner, location, and classification are usually present. The two that get skipped are support expiration date and recovery time objectives, both named explicitly in §500.13(a). An inventory missing them is not "complete and accurate" as the rule requires.