NYDFS section 500.3 requires written cybersecurity policies approved at least annually by a senior officer or the senior governing body, with procedures to match, based on the risk assessment. The text lists 15 areas to cover to the extent applicable, from information security to vulnerability management. Each maps to an engineering document.
This is general information, not legal advice.
The 15 areas and their backing documents
| Area in 500.3 | Engineering document that supports it |
|---|---|
| (a) Information security | Security standard and control list |
| (b) Data governance, classification and retention | Data classification and retention schedule |
| (c) Asset inventory, device management, end of life management | Inventory export, patching and retirement standard |
| (d) Access controls, remote access, identity management | Access standard, onboarding and offboarding runbook |
| (e) Business continuity and disaster recovery | BCDR plan and restore test record |
| (f) Systems operations and availability | Runbooks, service objectives |
| (g) Systems and network security and monitoring | Logging and monitoring standard |
| (h) Security awareness and training | Training plan and completion record |
| (i) Systems and application security, development and quality assurance | Secure development standard, test strategy |
| (j) Physical security and environmental controls | Facility and hosting provider evidence |
| (k) Customer data privacy | Privacy handling procedure |
| (l) Vendor and third party service provider management | Vendor review procedure and register |
| (m) Risk assessment | Documented risk assessment |
| (n) Incident response and notification | Incident response plan |
| (o) Vulnerability management | Vulnerability management standard with timelines |
"To the extent applicable to the covered entity's operations" lets a firm without physical data centers keep item (j) short and point to provider evidence.
Policy versus procedure
The rule asks for both. A policy states what must happen and who is accountable. Procedures say how. Engineering teams usually own the procedures, and the policy borrows their language. Keep the two linked so the annual approval of the policy does not drift from practice.
The annual approval
Approval must happen at least annually by a senior officer or the senior governing body. Keep a dated record, and note what changed. If nothing changed, say that you reviewed and confirmed. A common failure is approving the policy while procedures behind it are out of date, for example an inventory frequency that nobody follows.
Try it yourself
Click through it at your own pace, or open it full screen.
Look at how one piece of evidence can be mapped to several framework controls. The same idea works for policy topics.
Where Safeguard fits
Safeguard offers compliance and evidence automation along with policies, gates and guardrails, which can help produce evidence for the application security and vulnerability areas. The policy itself and its approval remain your decisions.
Mistakes to avoid
Policies fail when they copy another firm's text, so they describe controls the company does not run. They also fail when topics are covered in separate documents that nobody has mapped. Write each policy line so a team member can say yes or no to it today, and keep the table of areas to documents current so you can answer any examiner question about where a topic is covered.
Quick check
Must every one of the 15 areas appear?
The text says address them at a minimum to the extent applicable to the covered entity's operations. Record why an area is short or not applicable.
Who approves the policy?
A senior officer or the senior governing body, at least annually.
Sources
Last reviewed: 19 October 2026.
