NYDFS 500.7 requires you to limit access to what each job needs, limit privileged accounts, review all user access privileges at least annually, and remove or disable what is no longer necessary. Run it as a repeatable cycle: export, assign reviewers, decide, remove, and keep the record.
This is general information, not legal advice.
What section 500.7(a) lists
Based on the risk assessment, a covered entity shall:
- Limit access privileges on systems that provide access to nonpublic information to those necessary for the user's job.
- Limit the number of privileged accounts, and limit their functions to what the job needs.
- Limit use of privileged accounts to times when the work requires that access.
- Review all user access privileges periodically, and at a minimum annually, removing or disabling accounts and access no longer necessary.
- Disable or securely configure protocols that permit remote control of devices.
- Promptly terminate access following departures.
Subsection (b) adds a written password policy that meets industry standards where passwords are used.
The review cycle
Step one is the export. For each in-scope system, pull the list of accounts and their roles. Include source hosting, CI, cloud, databases, secrets stores and admin consoles. Include service accounts and tokens, since the definition of a privileged account in section 500.1 reaches both user and service accounts that can do security relevant functions.
Step two is assigning reviewers. A manager who knows the person's job is better placed than a central team. For service accounts, the named owner reviews.
Step three is the decision. Each line gets keep, reduce or remove, with a reason for anything kept at high privilege.
Step four is the change. Do not stop at the spreadsheet. Remove or downgrade access and confirm it took effect.
Step five is the record: the export, the decisions, the date, and the proof of changes.
Common findings
| Finding | Typical fix |
|---|---|
| Former contractors still listed | Link access removal to the offboarding checklist |
| Admin rights held for convenience | Move to time bound elevation |
| Shared accounts | Replace with named accounts and logging |
| Tokens with no owner | Assign an owner or revoke |
| Remote admin protocols left on | Disable or secure and document |
Make it more than once a year
The text sets a floor of annual review. Departures need prompt action, so wire removal into HR events rather than waiting for the cycle. A light quarterly pass on privileged accounts keeps the annual one short.
Mistakes to avoid
Reviews go wrong when the reviewer cannot tell what a role allows, so approvals are rubber stamps. Another gap is reviewing people but not tokens, keys and service accounts. A third is recording decisions without verifying the removal. Describe roles in plain language beside each entry, include machine identities, and sample a few removals after the review to confirm they took effect.
Quick check
Do service accounts count?
The definition of privileged account in 500.1 covers any authorized user account or service account that can perform security relevant functions, so privileged service accounts belong in the review.
Is a manager's email approval acceptable evidence?
The rule asks for the review and the removal of unnecessary access. Keep a dated record of decisions in a form you can produce, and make sure the changes were actually applied.
Sources
Last reviewed: 19 October 2026.
