Access review is preventive governance that checks whether an identity still needs permission to PHI. Breach notification is a post-incident legal obligation that starts after unauthorised access, use, or disclosure is suspected and the organisation must assess whether compromise is likely.
How the two differ in purpose and timing
access review and breach notification sit on opposite sides of the control timeline. Access review is a governance control that asks whether an identity, role, or entitlement is still justified before a problem occurs. Breach notification is an incident response and legal process that begins after suspected unauthorised access, use, or disclosure and the organisation must assess reporting duties.
The practical difference is that access review is designed to prevent excessive or stale access from lingering, while breach notification is designed to respond to a suspected security event and meet statutory deadlines. One is part of routine access governance, the other is triggered by a potential compromise and often involves counsel, privacy, security, and operations.
Access review usually operates on a scheduled or event-driven cadence, such as quarterly recertification, role change, or access request closure. Breach notification is event-led: once an organisation believes protected information may have been accessed or disclosed without authorisation, the organisation moves into evidence collection, impact assessment, and notification decision-making.
What each one is trying to prove
Access review is proving necessity. The question is whether the person, service, or other identity still needs the access it has, and whether that access matches job function, business purpose, and least-privilege expectations. Good reviews should remove unused access, correct excess permissions, and surface ownership gaps before they become exposure.
Breach notification is proving whether an incident crosses a reporting threshold. The organisation must determine what happened, what information was involved, whether the event likely created compromise or unlawful disclosure, and who must be notified. In healthcare and similar regulated settings, that assessment often hinges on whether the information was actually compromised or merely exposed briefly.
That is why the evidence needed is different. Access review relies on entitlement evidence, managers or system owners, role rationale, and whether the access is still business-justified. Breach notification relies on logs, incident timelines, forensic findings, containment actions, and legal or regulatory criteria for when a notification obligation begins.
How to avoid confusing governance with incident response
A clean way to separate the two is to ask whether the question is “Should this access exist?” or “Has this access already been misused or exposed?” The first is an access governance question. The second is an incident and reporting question. If teams blur them, they often delay containment while they debate permissions, or they over-focus on compliance paperwork before they understand the event.
The distinction also matters for ownership. Access review is normally owned by IAM, application owners, line managers, or governance teams. Breach notification usually belongs to incident response, privacy, legal, and compliance, with security supplying the facts. Treating both as the same process causes weak handoffs and missed deadlines.
For related identity-governance detail, see the IAM and IGA Basics discussion of access governance and the Access Reviews and Certification Guide on closing review loops instead of rubber-stamping access.
Risk and Threat Considerations
Confusing the two creates real exposure. If a team treats breach notification like an access review, it may spend time re-validating permissions while the incident remains uncontained. If it treats access review like a breach workflow, it may over-escalate routine entitlement cleanup and waste response capacity on non-incidents.
Failure mechanism: stale access, weak review quality, or delayed revocation can leave a sensitive system exposed long enough for misuse, while an actual incident can be underreported if teams do not recognise that suspected unauthorised access has crossed a legal threshold.
Impact: the organisation can end up with avoidable overprivilege, missed detection of suspicious access, late notification, regulatory penalties, or a lost ability to reconstruct what happened.
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 sets the technical controls, while ISO/IEC 27001:2022 defines the regulatory obligations.
| Framework | Control / Reference | Relevance |
|---|---|---|
| NIST SP 800-53 Rev 5 | AC-2 — Account Management | Access reviews assess whether entitlements still match business need. |
| AU-6 — Audit Record Review, Analysis, and Reporting | Breach notification depends on logs and incident facts to assess suspected access. | |
| IR-6 — Incident Reporting | Breach notification is the reporting phase after suspected unauthorised access. | |
| Recommendation — Review account access regularly and remove unnecessary or stale entitlements. Use audit records to support incident scoping and notification decisions. Establish incident reporting triggers and notification decision paths. | ||
| ISO/IEC 27001:2022 | A.5.15 — Access control | Access review is a core access-control governance activity. |
| A.5.24 — Information security incident management planning and preparation | Breach notification sits inside incident management preparation and response. | |
| Recommendation — Apply access-control reviews to keep permissions aligned to need. Prepare incident workflows that decide when notification is required. | ||
Practitioner Guidance
What to verify: For access reviews, verify that each entitlement has a named business owner, a current justification, and a clear removal path if the answer is “no longer needed.” For breach notification, verify the incident timeline, affected data type, and whether there is credible evidence of unauthorised access or disclosure before deciding the notification workflow.
Decision rule: If the question is about whether access should remain in place, treat it as governance and entitlement hygiene. If the question is about suspected unauthorised access, treat it as an incident until counsel or the incident lead decides otherwise.
Practitioner takeaway: Strong programmes keep access review and breach notification separate, but connected, the former reduces the likelihood of incidents, and the latter ensures suspected incidents are assessed and reported on time.
Related resources from NHI Mgmt Group
- What is the difference between reviewing human access and reviewing NHIs?
- What is the difference between role-based access and API key governance for NHI security?
- What is the difference between protecting applications and protecting access?
- What is the difference between attack surface management and NHI governance?
Deepen Your Knowledge
Free weekly newsletter
Subscribe to the NHI & AI Identity Journal
The latest on NHI and Agentic AI security – articles, research, breaches, news and events every week.
Bonus 33% off our NHI Course when you subscribe.
Reviewed and updated by the NHIMG editorial team on October 7, 2026.
NHI Mgmt Group — the #1 independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org