Approved Software List for CMMC: What to Record and Why

An approved software list is the document that connects your policy to your enforcement. The allowlisting policy says that only approved software may run. The enforcement tool blocks everything else. The list says what "approved" means in practice, and it is the first thing an assessor will ask to see.

Building an approved software list CMMC assessors can follow

A list is easier to defend when each entry answers the questions an assessor is likely to ask: what is it, which version, who approved it, why, and what evidence supports the decision. A bare list of product names answers none of them.

Use one record per application version or per approved version range. The minimum fields are the application name, the approved version or range, the publisher, the signature status, the SHA-256 hash of the installer, the business owner and justification, the approver and approval date, any conditions of use, and the next review trigger. These fields are described in more detail in the CM.L2-3.4.8 guide.

Version policy: exact, range or publisher

Decide how precisely you approve. Approving an exact version with its hash gives the strongest evidence and the highest maintenance cost, because every update needs a new record. Approving a version range for a signed product from a trusted publisher reduces maintenance but widens what is trusted. Approving an entire publisher is the broadest option and should be limited to publishers with a narrow product line and a strong track record. Write the rule in your policy so that each entry follows it, and see the rule type comparison for how each choice maps to enforcement.

A hypothetical entry

To make the fields concrete, imagine a CAD viewer called ExampleViewer. Its entry would name the approved version range, 4.2 to 4.4, and the publisher, with the signature marked valid and the certificate subject recorded. It would carry the SHA-256 hash of the installer, the owning engineer and the business reason, the approver's name and the date, and the conditions: runs as a standard user, outbound traffic limited to the vendor's licensing host. The next review trigger is a major version change or the end of vendor support, whichever comes first.

Keep one source of truth

Lists drift when the same information lives in a spreadsheet, a ticketing system and the allowlisting tool. Pick one authoritative location and generate or reconcile the others from it. Run a periodic comparison between the list, the enforcement configuration and what is actually installed. Differences are findings to resolve, not noise.

The evidence pack behind each entry

For each entry, keep a small folder or record containing the request, the vendor screening result, the technical analysis report with hashes and observed behavior, the decision with its conditions and the implementation record, such as a policy export or change ticket. If a third party produced the analysis, store the report with its date and version. This pack is what turns the list from an inventory into evidence for the application execution policy. NIST SP 800-171A names the list of software authorized to execute, and the review and update records for that list, among the objects an assessor may examine for CM.L2-3.4.8.

Tie the list to the system security plan

Reference the list from your system security plan in the sections that describe configuration management. State where the list lives, who owns it, how often it is reviewed and how changes are approved. Your software inventory under the baseline configuration practice, CM.L2-3.4.1, should agree with the list. Where they differ, document why.

Review and retire

Set a review cycle and honor it. At each review confirm that the software is still in use, that the vendor is still supported and that no new vulnerability or ownership change affects the decision. Remove unused entries. An allowlist that only grows is an attack surface and an audit problem.

Where DigVel fits

The technical analysis and vendor screening that sit behind each entry are the most time-consuming part to build. DigVel's reports are designed to slot into an evidence pack: decision, hashes, observed behavior, conditions and NIST SP 800-171 mapping. See the report contents and the service. A report supports your evidence; your organization remains responsible for its own assessment.