Section 500.5 asks a covered entity to find vulnerabilities, hear about new ones, and fix them in order of risk. That means penetration testing at least annually, automated scans at a frequency set by your risk assessment, a monitoring process for new vulnerabilities, and timely remediation prioritized by the risk each one poses.
This is general information, not legal advice.
Duty one: look
Subsection (a) has two parts. First, penetration testing of your information systems from inside and outside their boundaries, by a qualified internal or external party, at least annually. Second, automated scans plus a manual review of systems the scans do not cover, to discover, analyze and report vulnerabilities. Scan frequency is set by the risk assessment, and scans also run promptly after any material system changes.
The practical reading: "annually" is a floor for testing, while scan cadence is your call, and a major change triggers a scan outside the normal schedule.
Duty two: hear
Subsection (b) says you must be promptly informed of new security vulnerabilities by having a monitoring process in place. A scan only tells you about what was known on the day it ran. The monitoring process covers the gap between scans, for example advisory feeds matched against your component list.
Duty three: fix
Subsection (c) asks you to timely remediate vulnerabilities, giving priority based on the risk they pose to the covered entity. There is no fixed day count. You define timelines in policy, and the risk ordering is the point.
| Duty | Question an examiner might ask | Evidence |
|---|---|---|
| Look | When were the last test and scans? | Report, scan logs, post-change scan record |
| Hear | How do you learn about new issues? | Feed or alert configuration, a sample alert and the action taken |
| Fix | How do you decide what goes first? | Prioritization rule, tickets with dates, closed items |
Prioritizing by risk
Severity score alone is a blunt tool. A defensible rule combines several signals: severity, whether the flaw is actively exploited, whether the vulnerable code is reachable in your application, whether the system holds nonpublic information, and whether a fix exists. Write the rule down and apply it the same way each time.
Try it yourself
Click through it at your own pace, or open it full screen.
Notice how findings are ordered and tracked from discovery to closure. That is the trail the fix duty asks you to keep.
Mistakes to avoid
Common gaps in this area include running a scan but not saving the output, treating the annual penetration test as a substitute for scanning, and tracking findings in several places so nobody sees the full picture. Another is skipping the scan after a material change, which the rule asks for explicitly. Keep scan history, keep one backlog, and add a post-change scan to your release process for large changes.
Where Safeguard fits
Safeguard offers dependency scanning, reachability analysis and autonomous remediation with fix pull requests, which is off by default and set to manual for every category. Those can support the look and fix duties. You can try a free scan at gold.safeguard.sh/scan.
Quick check
Does 500.5 say how fast critical issues must be fixed?
No. It requires timely remediation with priority based on risk. Your policy sets the timelines.
Are scans enough without a penetration test?
No. The rule lists annual penetration testing and automated scanning as separate minimums.
Sources
Last reviewed: 19 October 2026.
