They know by checking whether the control produces current, repeatable evidence across access reviews, MFA enforcement, testing, and vendor oversight. If the evidence is stale, incomplete, or cannot be tied to real identities and systems, the programme may be compliant in appearance but not in operation.
What “working” means for NYDFS controls
For NYDFS, a control is not proven by policy text alone. Security teams need evidence that the control operates continuously in the real environment, against current users, systems, and vendors, and that the output is repeatable enough to survive challenge by audit, testing, and incident review. The question is operational effectiveness, not policy existence.
That is why current evidence matters more than a one-time attestation. If access reviews, MFA checks, vendor reviews, and test results cannot be tied back to named identities, systems, and dates, the control may exist on paper while failing in practice.
Teams usually judge this by asking three questions: did the control run, did it cover the intended population, and did it produce a result that changed risk or corrected exceptions. A control that never surfaces exceptions, never creates remediation work, or cannot be repeated on demand is usually too weak to trust.
How teams prove control operation across access, MFA, testing, and third parties
The most useful evidence is control-specific and time-bounded. Access reviews should show who was reviewed, what access was evaluated, what was removed, and when the review occurred. MFA enforcement should show both policy configuration and observed authentication outcomes, not just an expected-state screenshot. Testing should demonstrate that control checks are exercised, fail when they should, and are retested after remediation.
Vendor oversight needs the same discipline. Teams should be able to show how third-party access is approved, monitored, recertified, and revoked, and how exceptions are tracked to closure. This is where regulatory and audit perspectives on identity governance are useful because they connect compliance expectations to evidence that actually demonstrates control operation.
Where the control depends on privileged or shared access paths, the evidence should also show ownership and accountability. Financial services identity security guidance is especially relevant here because NYDFS-style controls often fail when ownership, review cadence, and remediation responsibility are unclear. A good programme leaves a paper trail that explains not just the control, but the action taken after the control found something.
Repeatability is the real test. If one reviewer can reproduce the same evidence trail from the same systems and obtain the same conclusion, confidence is high. If the result depends on manual memory, ad hoc exports, or a single person’s interpretation, the control may be fragile even if the initial report looks clean.
Signals that a NYDFS control is only compliant in appearance
The biggest warning sign is stale evidence. A quarterly report that reflects last quarter’s access state does not prove the current control state, and it may hide removals, exceptions, or missed approvals that happened after the report was produced. In practice, stale evidence often means the control has become a document exercise.
Another warning sign is incomplete population coverage. If the evidence covers employees but not contractors, production admins but not application owners, or direct users but not service accounts that support the same workflow, the control is narrower than the risk it is meant to manage. Gaps like that are especially dangerous when the organisation assumes a single review covers every access path.
A third sign is evidence that is disconnected from real systems. Screenshots, spreadsheets, and attestation emails may support a process, but they do not by themselves prove that the underlying control enforced anything. The closer the evidence is to the live system record, the more confidence teams can place in it.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
NIST SP 800-53 Rev 5 and CIS Controls v8 set the technical controls, while ISO/IEC 27001:2022 defines the regulatory obligations.
| Framework | Control / Reference | Relevance |
|---|---|---|
| NIST SP 800-53 Rev 5 | AU-6 — Audit Review, Analysis, and Reporting | NYDFS control effectiveness depends on reviewable, current evidence from systems and access events. |
| IA-2 — Identification and Authentication (Organizational Users) | MFA enforcement and real user authentication are central to proving access controls work. | |
| IA-5 — Authenticator Management | Current, repeatable evidence for credentials and MFA depends on lifecycle and enforcement of authenticators. | |
| Recommendation — Review audit outputs for current exceptions and verify remediation follows control failures. Validate that authentication settings are enforced in production, not just documented. Check authenticator lifecycle records for expiry, rotation, and revocation evidence. | ||
| ISO/IEC 27001:2022 | A.5.15 — Access control | Access reviews and entitlement oversight are core to showing operational control effectiveness. |
| A.5.23 — Information security for use of cloud services | Third-party and vendor oversight often depends on cloud and external service control evidence. | |
| Recommendation — Verify access decisions are reviewed, approved, and removed on schedule. Confirm third-party access and service controls are monitored and reviewed continuously. | ||
| CIS Controls v8 | CIS-6 — Access Control Management | NYDFS effectiveness is evidenced by account review, approval, and revocation in practice. |
| Recommendation — Reconcile accounts and privileges to a current owner and remove unapproved access. | ||
Practitioner Guidance
What to verify: Verify that each NYDFS control has an owner, a review cadence, and an artefact that can be regenerated from source systems rather than reconstructed by hand. If the evidence cannot be produced again with the same result, treat the control as immature even if the control design is sound.
What to measure: Track evidence freshness, exception closure time, review completion rate, and the percentage of samples that tie back to source records without manual correction. Those signals tell you whether the programme is operating or merely reporting.
Common mistake: Teams often confuse policy compliance with control effectiveness. A written standard for MFA or access review does not prove enforcement unless the evidence shows current coverage, remediation, and follow-through on exceptions.
Practitioner takeaway: The decisive question is not whether a NYDFS control exists, but whether its evidence proves live enforcement against the right identities, systems, and third parties.
Related resources from NHI Mgmt Group
- How do security teams know whether privacy controls are actually working?
- How do security teams know whether chatbot controls are actually working?
- How do security teams know whether password reset controls are actually working?
- How do security teams know whether their ISO 27001 controls are actually working?