What happens when a covered entity discovers an unauthorised access attempt under 23 NYCRR 500?

The reporting clock starts quickly. Covered entities must notify NYDFS within 72 hours after identifying an act or attempt, whether successful or unsuccessful, that was made to gain unauthorised access to, disrupt, or misuse an information system or the data stored on it. That requirement forces fast triage, evidence preservation, and clear incident escalation paths.

What NYDFS expects after an unauthorised access attempt

23 nycrr 500 treats an unauthorised access attempt as an incident trigger, not just a successful breach. Once a covered entity identifies an act or attempt to gain unauthorised access to, disrupt, or misuse an information system or the data on it, the reporting clock starts. The practical consequence is immediate classification, containment, and documentation, even if the attempt was blocked.

The key distinction is that the rule covers both successful and unsuccessful attempts. That means teams should not wait for confirmed exfiltration or system compromise before moving into incident handling. A credible attempt can still show control failure, hostile intent, or exposure that requires notification, evidence preservation, and escalation under the organisation’s incident process.

If the event is within scope, the entity should treat it as a regulated reporting matter first and a technical investigation second. That usually means confirming whether the activity was an attempt to gain access, a disruption effort, or misuse, then deciding whether the facts meet the NYDFS notice threshold and which internal owners need to be involved.

How the 72-hour reporting window changes incident handling

The 72-hour clock is short enough that weak intake or slow triage becomes a reporting risk on its own. Covered entities need a path from detection to legal, compliance, and security review that can operate the same day the event is found. In practice, that requires enough logging, alert fidelity, and decision authority to determine scope quickly.

This also changes evidence handling. Teams should preserve logs, endpoint artifacts, cloud control-plane records, identity events, and ticket history as soon as the attempt is suspected. If the organisation cannot reconstruct what happened before the window closes, it may be unable to support a defensible notice or later regulator follow-up.

For multi-team environments, the reporting requirement tends to expose ownership gaps. Security may spot the activity, infrastructure may control the affected system, and legal or compliance may own the notification decision. The rule works best when those roles are pre-assigned and the escalation path is tested before an incident occurs.

What counts as a regulated attempt, and why that matters

The operational test is broader than “was data stolen?” It includes attempts to gain unauthorised access, attempts to disrupt systems, and attempts to misuse systems or stored data. That breadth matters because it pulls blocked intrusions, failed exploit attempts, and suspicious misuse into the same response discipline when they are materially credible.

That does not mean every noisy alert is reportable. Practitioner judgement still matters when deciding whether an event is an actual attempt versus routine scanning, benign misconfiguration, or internal authorised testing. The threshold question is whether the observed activity is a real act or attempt directed at access, disruption, or misuse in a way the rule contemplates.

For covered entities, the safest interpretation is to build a decision tree around observed intent, target, and potential impact. If those elements are present, the event should move out of ordinary monitoring and into the incident-notification workflow immediately.

Risk and Threat Considerations

Short reporting windows create a control risk as much as a compliance risk. If detection, triage, and escalation are fragmented, the organisation can miss the 72-hour deadline even when the technical event itself was contained quickly. The same weakness also gives attackers more time to exploit uncertainty, suppress evidence, or repeat the attempt.

Failure mechanism: Delayed classification, unclear ownership, and incomplete telemetry prevent teams from proving when the entity identified the attempt and whether the event met the reporting threshold.

Impact: The organisation may submit a late or unsupported notice, lose evidentiary confidence, and weaken both regulatory defensibility and incident response quality.

Standards & Framework Alignment

This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.

NIST CSF 2.0 and NIST SP 800-53 Rev 5 set the technical controls, while ISO/IEC 27001:2022 defines the regulatory obligations.

Framework	Control / Reference	Relevance
NIST CSF 2.0	RS.CO-01 — Personnel know their roles and order of operations when a response is triggered	NYDFS notice timing depends on fast incident coordination and ownership.
Recommendation — Define notification roles and escalation paths so reportable incidents are identified and routed within the 72-hour window.
NIST SP 800-53 Rev 5	AU-6 — Audit Record Review, Analysis, and Reporting	Attempt detection and forensic reconstruction depend on timely log review and analysis.
Recommendation — Review and correlate logs quickly to establish whether the event was a reportable attempt.
ISO/IEC 27001:2022	A.5.24 — Information security incident management planning and preparation	The requirement demands prepared incident workflows for rapid reporting and escalation.
Recommendation — Prepare and test incident reporting procedures so notification can begin immediately after identification.

Practitioner Guidance

What to prioritise: Make the first-hour workflow about decision speed, not perfect attribution. If the event plausibly fits the NYDFS trigger, preserve evidence and escalate while the facts are still being established.

What to verify: Confirm the exact time the attempt was identified, the assets touched, the scope of the activity, and whether the event was blocked, partial, or successful. That timestamp is what anchors the 72-hour calculation.

Decision rule: If a credible attempt targets systems or data in scope, route it through the notification path even when the technical impact appears limited. Waiting for “more proof” is usually the wrong trade-off under this rule.

Practitioner takeaway: The hard part is rarely knowing that something happened, it is proving you recognised it fast enough and preserved enough evidence to support the notification decision.

NIST Cybersecurity Framework 2.0 CIS Controls v8 NIST AI Risk Management Framework