Re-Review Approved Software After a New Vulnerability

An approval record answers one question at one moment: was this software acceptable when we looked? Software changes, vendors change hands, and new vulnerabilities appear in products that were clean last quarter. An approved software list that is never revisited slowly turns into a list of assumptions. A defined re-review process keeps it honest and gives an assessor evidence that your controls operate over time.

Where the requirement comes from

Three NIST SP 800-171 Rev 2 practices, which CMMC Level 2 uses, point at this. RA.L2-3.11.2 requires scanning for vulnerabilities in systems and applications periodically and when new vulnerabilities affecting them are identified. SI.L2-3.14.1 requires identifying, reporting and correcting flaws in a timely manner. SI.L2-3.14.3 requires monitoring security alerts and advisories and taking action in response. None of them says "re-review the approval", but together they expect you to learn about new problems and act. A re-review is the way to show that you did.

Events that should trigger a re-review

A critical or actively exploited vulnerability. Subscribe to vendor advisories for approved products and watch the CISA Known Exploited Vulnerabilities catalog. When a listed flaw affects something on your list, check the version you run, whether a fix exists and whether the product is exposed.

A version change. A new release can add network behavior, services or drivers. If your allowlist uses hash rules, each update changes the hash and forces a decision anyway; see WDAC and AppLocker rule types.

An ownership or hosting change. Acquisitions can move a product under a different owner or move its servers. Repeat the screening described in vendor sanctions and ownership checks.

End of support. A product that no longer receives fixes is a growing risk and usually needs a replacement date.

New features. Telemetry, cloud sync and AI features change data flow and may need a fresh look.

A simple re-review procedure

1. Identify affected entries on the approved software list by product and version.
2. Check exposure: is the vulnerable component reachable in how you use the product?
3. Decide: keep, keep with new conditions, suspend until patched, or remove.
4. Act: deploy the fix, tighten the rule or block the product, and confirm the change took effect.
5. Record the trigger, the decision, the date, the approver and the evidence of enforcement.

For a critical, actively exploited flaw, do steps 1 to 3 the same day and treat the rest as time-bound work with an owner.

Who owns the process

Assign a named owner for the re-review process, usually the same role that approves new software. Without an owner, advisories arrive in a shared inbox and nobody checks them against the list. Give the owner a short list of sources, a defined response time for critical items and the authority to suspend a product while the question is open. Report the number of triggers handled and their outcomes to management on a regular schedule, because that report is also evidence that the practice is running.

Tier by risk

Not every product deserves the same cadence. Software that handles credentials, runs with elevated privileges or connects to external services should be reviewed more often than a stable offline utility. Write the tiers into the procedure so the schedule is a policy and not a mood.

Keep the evidence

Assessors look for proof that a control operated, not only that it exists. Keep dated records of advisories you received, entries you checked and decisions you made, including the cases where the answer was "not affected". The structure of the record is the one in the approved software list, with an added history of reviews.

Where DigVel fits

A first approval from DigVel gives you a documented baseline: vendor screening, sandbox analysis and a report mapped to NIST SP 800-171. A later re-review can repeat the analysis against a new version or after a new advisory. See the service overview and the approval workflow. A report supports your own assessment and does not replace it.