Section 500.6 requires systems, based on your risk assessment, that can reconstruct material financial transactions and that include audit trails designed to detect and respond to cybersecurity events likely to materially harm normal operations. The records required by the section must be kept for at least five years.
This is general information, not legal advice.
Two separate purposes
The rule has two limbs. They overlap in practice but serve different readers.
| Limb | Purpose | Reader |
|---|---|---|
| Transaction reconstruction | Rebuild material financial transactions to support normal operations and obligations | Finance, operations, auditors |
| Audit trails for cyber events | Detect and respond to events with a reasonable likelihood of materially harming operations | Security and incident responders |
Both limbs are qualified by "to the extent applicable and based on its Risk Assessment." Your risk assessment decides which systems need which trail.
What a useful security audit trail holds
The rule does not list fields, so use what an investigator would need on a bad day:
- Who: the account, and whether it was a person or a service.
- What: the action and the object it touched.
- When: a trustworthy timestamp, with clocks kept in sync.
- Where: source address or system.
- Result: success, failure or denial.
Priority sources include authentication events, changes to privileges, access to nonpublic information, administrative actions in cloud and CI systems, and changes to production configuration.
Integrity and the five year clock
An audit trail that an attacker can edit is weak evidence. Send logs to a store where application administrators cannot alter or delete them, and record who can read and who can change that store. Remember the retention floor of five years for records required by the section, and make sure storage cost planning reflects it. Hot searchable storage for recent data and cheaper archives for older data is a common arrangement.
Link logs to the incident plan
Section 500.16 asks for incident response plans that cover documentation and a root cause analysis. Logs feed both. A tabletop exercise that starts with the question "which log would tell us this?" tends to expose missing sources quickly.
A starting checklist
- List material systems and decide which trail each one needs.
- Confirm authentication and privilege change events are captured.
- Protect the log store from tampering.
- Set retention at five years or more for required records.
- Test that you can pull a transaction history on request.
Mistakes to avoid
Frequent weaknesses: logs kept on the same host they describe, so an intruder can wipe them; clocks that drift, which makes timelines unreliable; retention set by default storage limits rather than by the rule; and logs nobody has ever tried to search under pressure. Ship logs off host, sync time, set retention on purpose, and run a drill that asks the team to answer a real question from the logs within an hour.
Quick check
Is five years the retention period for every log?
Five years applies to records required by section 500.6. Other rules or your own policy may set different periods for other data.
Does 500.6 apply to every covered entity?
Section 500.19 lists 500.6 among the sections from which a limited exemption applies for small entities that meet the criteria. Check your status with your compliance team.
Sources
- 23 NYCRR 500.6, Audit trail
- 23 NYCRR 500.16, Incident response and business continuity management
- 23 NYCRR 500.19, Exemptions
Last reviewed: 19 October 2026.
