research
Auditing whether installed software matches the approved catalogue
A comparison method for finding applications that are installed but unapproved, approved but missing, or running outside the supported version range.
Use this benchmark to size repeatable IT work, set the review cadence, and decide what stays with the technical owner before assigning the workflow to an IT virtual assistant.
Research playbook
On this pageJump to section
Key stats
Key takeaways
Every company has a software catalogue and a separate reality on the endpoints. The catalogue lists what should be installed, while the inventory shows what actually is, including tools that arrived with a project and never left. This audit compares the two sets and classifies the differences by risk, licence exposure, and ownership. The output is a short list of decisions rather than a raw inventory dump.
Question and scope
This audit asks which installed applications are absent from the approved catalogue, which approved applications are missing, and which versions sit outside the supported range. The unit is one application on one managed device, and the population is the endpoints enrolled in the management console during a declared week. The result describes that fleet and that period, not the intentions of the catalogue owner. Freeze the catalogue version and the endpoint scope before collecting data.
Include laptops, desktops, and virtual workstations that run the management agent. Exclude servers unless the same catalogue governs them, because server software follows a different change process. Record any device that could not report and why, since an unreported device is itself a finding. State the collection date in every table so the reader knows which catalogue it was compared against.
Define the catalogue and the installed set
Record the approved title, the supported version range, the owner, and the licence type for each catalogue entry. Note whether the approval covers all staff or a named group. A title without a version range is not a usable standard, because it cannot tell an old build from a supported one. Keep the catalogue as the single source rather than merging it with an older spreadsheet. A catalogue entry without an owner should be treated as unapproved until someone claims it.
Build the installed set from the management console rather than from a user survey. Include applications installed per user as well as per machine, because the console may store them in different tables. Exclude operating system components and drivers that are patched separately. Record the install source so a store app and a manually installed package are not treated as the same entry.
Build the comparison frame
Export the device identifier, the application name, the publisher, the version, the install date, and the install source. Add the last-seen date so a stale record can be distinguished from a live install. Keep the original name string beside the normalised name. Normalisation is necessary, but it should be reviewable when a match looks wrong. Save the query text beside the export so the comparison can be repeated after a console change.
Reconcile the export count with the console's own device and application totals before comparing. Large fleets often contain duplicate records from reinstalled agents or renamed devices. Deduplicate by device and application while keeping the most recent observation. Record the number of devices that could not be read, because a comparison that quietly drops them overstates coverage.
Reconcile versions and editions
Compare each installed version with the supported range rather than with a single version number. Note edition differences, because a professional edition may carry features the standard licence does not permit. Check the update channel, since a beta build can be installed on a production device without appearing unusual. Flag any version that the publisher no longer supports.
Record the rule used to judge the version so another reviewer can apply it the same way. If the catalogue allows a range, show the lowest and highest supported build. Treat an unknown version as unverified rather than compliant. The goal is a consistent classification, not a perfect match on every build number.
Sample and verify on the endpoint
Select a random sample of at least thirty differences and verify them directly on the device. Open the installed programs list, confirm the version, and check whether the application is actually used. A console record can outlive an uninstall if the agent did not report the change. Record the verification method and the person who checked. Do not let a remote check replace the endpoint visit, because the console is the thing being tested.
For applications that run as services, confirm the service state and the account it uses. For browser-based tools, check whether the application is a local client or only a web link. Do not count a shortcut as an installed application. The sample exists to test the console data, not to repeat it.
Classify the differences
Group the findings into unapproved but low risk, unapproved with a licence cost, unapproved with access to company data, approved but missing, and version drift. Give each group an owner and a decision. A remote-access or file-sync tool belongs in the data-access group even when it is free. A missing security agent belongs in the highest-risk group regardless of its licence cost.
Record the number of devices affected by each group and the business reason where it is known. Do not assume an unapproved tool is unwanted, because a project may have approved it outside the catalogue. Ask the owner before removing anything that supports live work. The classification should separate a documentation gap from a genuine control failure.
Estimate the exposure
Count the devices with unapproved tools that can read, sync, or remotely control company data. Report that count beside the total managed fleet and the number of devices that could not be read. Use invoices or the finance system for licence cost rather than a public price list. If the cost is unknown, report the number of unlicensed installs and let the owner obtain a quote.
Describe the exposure in operational terms such as data leaving the managed environment or an unsupported application receiving no security updates. Avoid inventing a breach probability or a financial loss figure. The audit can show what is present and what policy says, but it cannot prove what has not happened. Keep the estimate tied to the evidence in the sample.
Report to the owner
Lead with the number of devices checked, the share that matches the catalogue, and the highest-risk differences. Show one example of a version drift and one example of an unapproved tool with data access. Put the full comparison in an appendix. The owner should be able to see the decision in the first page. Keep the chart simple enough that the decision is visible without a walkthrough.
Ask for specific decisions such as approving a tool, removing an unapproved one, or extending a version range. Name the owner and the review date for each. If the decision is to keep the current state, record the reason and the compensating control. A written decision is what turns an audit finding into a managed exception.
Limits and next use
The comparison depends on console coverage, naming quality, and the catalogue being current. It does not detect applications that run without an install record, such as portable executables or web applications. It also cannot confirm that an approved application is configured securely. State those limits so the result is not read as a complete software inventory.
Repeat the comparison monthly for the high-risk groups and quarterly for the full catalogue. Compare the counts over time and investigate a sudden change. If the same unapproved tool keeps appearing, the catalogue may be missing a real need. Use that signal to review the requirement rather than to repeat the same removal.
Set the review cadence
Assign the monthly comparison to one person and the quarterly review to the catalogue owner. Keep the export query and the normalisation rules in the review folder so the process does not depend on memory. Record the date, the counts, and the decisions in a short log. A cadence that survives staff changes is more valuable than a one-time cleanup.
Review the catalogue itself at the same time, removing titles that are no longer used and adding tools that have been approved. Confirm that every entry still has an owner and a supported version range. Report the number of open exceptions and their age. The audit is working when the differences are explained rather than when the count reaches zero.
Sources and next step
Use the NIST Cybersecurity Framework 2.0 and the CISA Cross-Sector Cybersecurity Performance Goals as primary references for the recovery, software inventory, service desk, DNS, and endpoint protection controls discussed here. The GAO data reliability guidance supports the sampling and verification approach used in these methods. Apply your own policies, contracts, and system documentation when adapting the method.
Compare this study with the endpoint encryption coverage study and the public DNS change authority audit before combining them into one review cycle. If the measurement work is recurring and your technical owner can define the scope, review the service areas and contact ITVirtualAssistant to discuss a limited pilot.
Benchmark brief
What this research page must produce
A practical estimate for volume, review time, escalation rate, and assistant capacity.
A clear split between routine support, preparation work, and technical ownership.
What the auditing whether installed software matches the approved catalogue data shows
Treat this as a planning benchmark, not a universal number. Compare the benchmark against your ticket volume, SaaS stack, documentation backlog, and support risk before assigning recurring work.
The useful output is a decision about capacity, not a static statistic. If the workflow is high volume and low judgment, an IT virtual assistant can absorb coordination and upkeep. If the workflow is low volume but high risk, keep it with the technical owner and use the assistant only for preparation, reminders, and documentation.
Workflow
Recommended operating workflow
Collect a baseline
Pull the last 30 to 90 days of examples related to auditing whether installed software matches the approved catalogue, including completed work and unresolved exceptions.
Classify the work
Tag each item by routine admin, manager approval, technical decision, security risk, or vendor dependency.
Set the operating number
Use the median weekly volume and review time to decide how many assistant hours the workflow deserves.
Refresh the benchmark
Recheck the numbers quarterly so tool growth, new systems, and security requirements do not silently change the scope.
Decision rules
| Metric | Use it to decide | Manager action |
|---|---|---|
| Weekly volume | Whether the workflow is worth assigning as recurring assistant work. | Approve a weekly capacity target and backlog threshold. |
| Access sensitivity | Whether the assistant can work directly or only prepare review notes. | Set least-privilege permissions and removal dates. |
| Escalation rate | Whether the workflow is stable enough to delegate. | Rewrite the SOP when exceptions exceed the agreed threshold. |
Consolidated statistics
| Statistic | Figure | Source |
|---|---|---|
| Sample floor | 30 differences | Study protocol |
| Finding groups | 5 | Study protocol |
| Review cadence | Monthly and quarterly | Study protocol |
Sources
- NIST SP 800-128, Guide for Security-Focused Configuration ManagementConfiguration baseline and change control practices for software inventories.
- NIST SP 800-53 Rev. 5Software inventory, configuration, and least-functionality controls.
- CISA Cross-Sector Cybersecurity Performance GoalsAsset and software inventory goals for small organizations.
- NIST Cybersecurity Framework 2.0Asset management and governance outcomes for endpoint software.
- GAO Assessing Data ReliabilitySampling and verification checks for inventory comparisons.
Measurement checklist
| Field | What to capture | Owner |
|---|---|---|
| Volume | Weekly request count, backlog age, and repeat issue patterns | Assistant prepares, manager reviews |
| Risk | Access level, customer impact, security sensitivity, and approval needs | Technical owner |
| Cadence | Daily, weekly, monthly, or quarterly review rhythm | Manager |
| Evidence | Sample tickets, logs, screenshots, and before-after examples | Assistant collects, owner validates |
| Escalation | Triggers, approval path, response time, and stop-work rules | Technical owner |
How to read the result
A good research page should leave the manager with a working number and a clear boundary: what the assistant can do every week, what the assistant can prepare for review, and what must never move without the accountable technical owner.
Source and refresh note
This planning page is dated for 2026 and should be refreshed quarterly as tool stacks, ticket patterns, and security expectations change.
How should teams use this benchmark?
Use it to define task volume, access limits, review cadence, and escalation rules before assigning work.
Get free benchmark review