A financial-services group may operate one identity platform and one security team for several legal entities. That arrangement makes administration easier, but it does not automatically show which systems or users a control actually covers. For Part 500 technical work, make the relationship between the entity, service and tested population explicit.
Map the entity boundary before testing controls
Counsel and accountable officers determine which entities and requirements apply under 23 NYCRR Part 500. Technical owners then map those entities to subscriptions, directories, networks, applications, providers and data stores. Record shared services and acquired businesses separately when their controls or administration differ.
Reconcile the scope against system records. An inventory maintained by procurement may miss a cloud service created by a business unit. A vulnerability dashboard may exclude a network segment that cannot be scanned. Explain those variances instead of treating a single system's export as complete.
Collect evidence of operation, not just design
For each tested control, record the expected condition, covered population, evidence period and observed result. A policy describes intent; configuration and activity records show what was in place. Sampling can be appropriate, but the sample selection and exclusions must remain visible.
- Identify the control owner and the entities using the service.
- Retain dated configuration exports and relevant operating records.
- Map test findings to affected systems, not only a corporate risk register.
- Record exceptions, compensating measures and approval history.
- Retest the original failure condition after remediation.
Keep central reporting connected to local evidence
A group-wide completion percentage can conceal an untreated high-consequence system. Report coverage and exceptions at a level that lets an accountable owner make a decision. For inherited findings after an acquisition, identify who owns remediation and whether the evidence predates the current architecture.
A successful technical test is not a legal compliance certification. DFS's September 10, 2026 risk-assessment guidance (opens in a new tab) supports a record connecting identified risks to chosen controls and shared-system dependencies. It explains existing obligations. The DFS cybersecurity resource center provides current requirements, exemptions and reporting guidance. The entity and counsel determine applicability and legal conclusions.
See NYDFS penetration-testing services for New York practice scope, vulnerability assessments for coverage analysis, and penetration testing for controlled technical validation.
Part 500 provisions behind the technical scope
Source checked October 7, 2026: the DFS regulation identifies vulnerability management in section 500.5, audit trails in section 500.6, access privileges and management in section 500.7, and incident response and business continuity in section 500.16. These are scope references, not a determination that every provision applies to every entity.
Read sections 500.5 and 500.6 in the current DFS text (opens in a new tab); section 500.7 (opens in a new tab); and section 500.16 (opens in a new tab). Counsel and accountable officers must also consider definitions, exemptions and the entity’s applicable requirements.