Control template: NYDFS 23 NYCRR Part 500 (Cybersecurity Regulation)

Status: Stable · Version: nydfs-part-500/v1.0.0

A bundle of CALM control snippets covering the architecturally enforceable subset of the New York Department of Financial Services Cybersecurity Regulation (23 NYCRR §§500.0–500.24, as amended November 2023). You copy these into your *.calm.json files on the nodes that are part of your Covered Entity's Information Systems handling Nonpublic Information.

Who Part 500 applies to

Covered Entities: any individual or non-governmental entity operating under or required to operate under a license, registration, charter, certificate, permit, accreditation, or similar authorization under New York's Banking Law, Insurance Law, or Financial Services Law. Common categories: - New York-chartered banks and trust companies - Foreign banks with New York branches - Licensed insurers and insurance producers - Money transmitters, virtual currency businesses (BitLicense) - Mortgage lenders, brokers, and servicers - Premium finance agencies

Class A Companies (§500.1(d)): Covered Entities with $20 million in gross annual revenue from NY operations over the last 2 fiscal years AND either (i) over 2,000 employees averaged over the last 2 fiscal years OR (ii) over $1 billion in gross annual revenue averaged over the last 3 fiscal years. Stricter expectations apply to Class A.

Limited exemptions exist under §500.19 (employee-only firms, small firms with <20 employees + <$7.5M NY revenue + <$15M total assets). Confirm your category with counsel.

What this template covers

Part 500 has 24 sections. The architectural surface concentrates in §§500.5–500.16. Governance (§500.4 CISO), risk assessment (§500.9), training (§500.14(b)), and incident reporting workflow (§500.17) are documented separately in your cybersecurity program.

Part 500 citation	Architectural surface	Control alias
§500.6 — Audit trail	Audit logging on Nonpublic Info	`nydfs-audit-trail`
§500.7 — Access privileges	RBAC + privileged-access governance	`nydfs-access-privileges`
§500.15 — Encryption	Encryption of Nonpublic Information	`nydfs-encryption`

3 architectural controls covering Part 500's implementation-shaped surfaces. Governance (§500.4 CISO designation), risk assessment (§500.9), training (§500.14(b)), policies (§500.3), and the annual Certificate of Compliance (§500.17(b)) are organizational and live in your firm's cybersecurity program.

The "NYDFS-in-scope" pattern

A node is NYDFS-in-scope if it is part of an Information System of a Covered Entity, particularly any system that handles Nonpublic Information as defined in §500.1(k) (business information that would cause material adverse impact; personal information; biometric data; health information).

{
  "unique-id": "policy-administration-system",
  "node-type": "service",
  "name": "Policy Administration System",
  "metadata": {
    "nydfs-in-scope": true,
    "nydfs-class-a": true,
    "handles-nonpublic-info": true,
    "data-classification": "nonpublic-information"
  }
}

Class A status drives stricter expectations for several controls (annual independent audit, more frequent risk assessments, dedicated monitoring solutions).

Infrastructure verification. ArchRails now verifies the following controls against your infrastructure at PR review time and during code generation (AWS): nydfs-audit-trail, nydfs-encryption.

Control snippets

Copy each block under the controls key of the node it applies to.

§500.6 — Audit trail (`nydfs-audit-trail`)

Per-node. Audit trail design + retention.

"nydfs-audit-trail": {
  "description": "NYDFS Part 500 §500.6 — audit trails to detect and respond to Cybersecurity Events with sufficient detail to support investigations, retained for at least 5 years (3 years for some categories per §500.6(a)(2)).",
  "requirements": [
    {
      "requirement-url": "https://archrails.io/catalog/req/nydfs-part-500/audit-trail",
      "config": {
        "control-id": "nydfs-audit-trail",
        "required-fields": ["access-to-nonpublic-info", "privilege-elevation", "config-change", "policy-violation", "auth-success", "auth-failure"],
        "destination": "centralized-siem",
        "immutable": true,
        "retention-days": 1827
      }
    }
  ]
}

§500.7 — Access privileges (`nydfs-access-privileges`)

Per-node.

"nydfs-access-privileges": {
  "description": "NYDFS Part 500 §500.7 — limit user access privileges to Information Systems that provide access to Nonpublic Information. Privileged access controlled per §500.7(a)(3)–(6).",
  "requirements": [
    {
      "requirement-url": "https://archrails.io/catalog/req/nydfs-part-500/access-privileges",
      "config": {
        "control-id": "nydfs-access-privileges",
        "principle": "least-privilege",
        "review-frequency": "at-least-annual",
        "privileged-access-jit-or-pam": true,
        "remote-privileged-access-additional-controls": true
      }
    }
  ]
}

§500.15 — Encryption (`nydfs-encryption`)

Per-node.

"nydfs-encryption": {
  "description": "NYDFS Part 500 §500.15 — encryption of Nonpublic Information in transit over external networks AND at rest. Compensating controls required where encryption is infeasible.",
  "requirements": [
    {
      "requirement-url": "https://archrails.io/catalog/req/nydfs-part-500/encryption",
      "config": {
        "control-id": "nydfs-encryption",
        "at-rest-algorithm": "AES-256-GCM",
        "in-transit-minimum-tls": ["1.2", "1.3"],
        "key-management": "hsm-or-kms-cmk",
        "key-rotation-days": 365,
        "compensating-controls-document-url": "https://internal.example.com/nydfs/encryption-exceptions"
      }
    }
  ]
}

What the engine actually enforces

There is no NYDFS-specific cross-cutter — the engine has no "if nydfs-in-scope: true, require these controls" sweep. Enforcement is graph-driven: you attach a control where you want it enforced; the absence of an attach is opt-out by silence.

For the 3 NYDFS Part 500 controls above, here is the honest split:

Enforced via attestation (constraint engine)

Every snippet's config block is read by the constraint engine: presence / exact / enum / set_required / set_forbidden shapes are inferred from what you authored, and the agent's declared_pattern must satisfy them. This applies to TLS version, retention days, the access-control principle, and the audit-trail event set.

Enforced via sensitivity-gated validators (separate path)

When a node declares data-classification: nonpublic-information / confidential / restricted / pii / phi / pci, a set of always-on architectural validators fires on changes to that node's code — independent of which NYDFS controls you've authored. These cover:

Secret detection — substantive enforcement against credentials inadvertently committed near Nonpublic-Information code paths
Weak crypto — deprecated algorithms on Nonpublic-Information nodes (substantive enforcement for §500.15 encryption intent)
Authorization — sensitive nodes must have an authz layer (substantive enforcement for §500.7 access-privileges intent)
Edge protocol — plaintext protocols on edges touching Nonpublic-Information nodes (substantive enforcement for §500.15 in-transit encryption intent)
Sensitive fixture detection — real-looking Nonpublic-Information literals committed to governed files
Retention — required retention windows on Nonpublic-Information data stores (substantive enforcement for §500.6 audit-trail retention intent)

And the diff-walking AR-REL-008 validator fires on any outbound call from an NYDFS-scope node to an external host that the node's allowed_connects doesn't declare — substantive enforcement for the §500.11 third-party Information Systems mapping intent (an un-declared egress IS an unmapped third-party connection).

All checks are deterministic — pure function over your CALM JSON. The same constraint engine handles PCI DSS, GDPR, SOC 2, HIPAA, NIST CSF 2, ISO 27001:2022, MiFID II, and any controls you author yourself.

Class A considerations

If nydfs-class-a: true is set on the node, your firm has stricter expectations under several sections (independent audit, more frequent risk assessments, dedicated monitoring solutions). This template's defaults are tuned for non-Class A; Class A firms should tighten the values (e.g., automated-scanning-frequency: continuous, review-frequency: quarterly).

Versioning

This is nydfs-part-500/v1.0.0 — the first stable cut. Each surviving control has per-validator firing tests + cross-language coverage across 11 Tier A languages (Python, Java, C#, TypeScript, Go, Kotlin, Scala, Rust, Ruby, Swift, PHP). Future bumps: v1.x.y for additive controls and substantive validator coverage; v2.0.0 for breaking changes (control retired, semantics changed). Updates as authoritative guidance or enforcement priorities materially shift.

Out of scope for this template

§500.3 — Cybersecurity policy — written policy is procedural.
§500.4 — CISO designation + annual report — governance.
§500.9 — Risk assessment methodology — process.
§500.10 — Cybersecurity personnel + intelligence — organizational.
§500.14(b) — Cybersecurity awareness training — HR / training.
§500.17(b) — Annual Certificate of Compliance — signed by Senior Officer or Senior Governing Body, not architectural.
§500.19 — Exemption determination — legal, not architectural.

For those surfaces, pair this template with your cybersecurity program documentation and engage qualified counsel.