A software audit is a structured review of the applications in use across an organisation. It helps teams identify sanctioned and unsanctioned tools, duplicate subscriptions, and hidden operational risk. In practice, audits support governance by showing where controls, ownership, and approval processes need to be tightened.
What a software audit is used for
A software audit is more than an inventory exercise. It creates a controlled view of what is actually installed, subscribed to, and approved, so teams can compare usage against policy, ownership, and budget. For governance teams, that visibility is the starting point for deciding which applications are sanctioned, which are redundant, and which need formal review.
Because the term spans discovery, approval, and control, a software audit often sits at the intersection of governance, procurement, security, and operations. In mature organisations, the audit output becomes a working record for follow-up actions such as rationalising tools, tightening approvals, and clarifying who owns each application.
What a software audit typically examines
The scope usually includes installed software, cloud subscriptions, browser-based tools, shadow IT, and duplicate products that solve the same problem. It may also examine where software was introduced, who approved it, whether licences are still in use, and whether the deployment matches policy or contractual terms.
That broader view matters because the real finding is often not the application itself, but the gap between declared control and actual usage. A clean audit should reveal where the approved software list is incomplete, where ownership is unclear, and where users have adopted tools outside formal governance channels.
When audits are tied to security reviews, they can also surface SOC 2 Trust Services Criteria concerns, especially where software inventory, change control, and access governance affect vendor assurance or internal control evidence.
Why software audits matter for governance and control
Software audits support control by showing where the organisation is exposed to duplication, unowned tools, unsupported applications, and inconsistent approval paths. They also make it easier to align procurement decisions with actual usage, rather than relying on assumptions or isolated team knowledge.
For security teams, the same audit can expose hidden dependencies, unreviewed integrations, and software that bypasses standard onboarding or review processes. For finance and operations, it can reduce wasted spend and help rationalise overlapping subscriptions before they become long-term maintenance burdens.
audit evidence is especially useful when the organisation needs to demonstrate that software is governed consistently. That is why a structured review often complements broader control baselines such as NIST SP 800-53 Rev 5 Security and Privacy Controls and the governance function in NIST Cybersecurity Framework 2.0, both of which depend on clear inventory, oversight, and control validation.
Common software audit failure modes
Software audits often fail when the organisation treats them as a one-time clean-up instead of an ongoing governance process. Inventory data goes stale quickly, especially when teams can procure apps through self-service purchasing, browser extensions, or SaaS trials that never pass through central review.
Another common failure mode is incomplete ownership. If no one is accountable for a tool, it is harder to assess whether it should remain in use, be renewed, be retired, or be restricted. That gap can leave unsanctioned software in place long after it should have been removed.
Audit quality also drops when discovery and approval records are disconnected. A tool may appear in procurement records but not in the endpoint estate, or it may exist in the environment without a corresponding business owner. In both cases, the organisation has visibility, but not enough governance to act with confidence.
How software audits relate to broader control frameworks
A software audit is usually the operational expression of wider governance principles rather than a standalone security discipline. It supports controls around asset visibility, approval, change management, and acceptable use, which is why it maps naturally to enterprise security programmes.
For organisations managing cloud services or SaaS-heavy estates, the audit process may also overlap with identity and access governance, because software use often depends on account provisioning, entitlement review, and tool approval. The deeper the dependency on shared access, the more important it becomes to keep audit evidence aligned with the actual control environment.
Where software inventories include third-party applications or externally managed services, broader governance references such as NIST Cybersecurity Framework 2.0 and SOC 2 Trust Services Criteria help translate inventory findings into control expectations, evidence needs, and accountability decisions.
Risk and Threat Considerations
Software audits matter because unmanaged applications create real exposure: unsanctioned tools can move data outside approved controls, duplicate products can expand the attack surface, and abandoned subscriptions can conceal lingering access paths. The risk is usually not the presence of software itself, but the loss of visibility and ownership around it.
Failure mechanism: Shadow IT, stale inventories, and unclear approval chains allow software to persist without proper review, making it harder to detect unapproved data handling, weak configuration, or unnecessary access.
Impact: The organisation can end up with uncontrolled business risk, poor audit evidence, unnecessary cost, and security gaps that survive normal governance checks.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
NIST CSF 2.0 and NIST SP 800-53 Rev 5 set the technical controls, while SOC 2 (AICPA) and ISO/IEC 27001:2022 define the regulatory obligations.
| Framework | Control / Reference | Relevance |
|---|---|---|
| SOC 2 (AICPA) | CC8.1 — Change Management | Software audits verify controlled software changes and approvals. |
| Recommendation — Use CC8.1 to keep software introductions and removals under formal review. | ||
| NIST CSF 2.0 | GV.OC-01 — Organizational Context | Software audits establish what tools the organisation actually uses and owns. |
| ID.AM-01 — Physical Devices and Systems Inventoried | Inventory discipline underpins software discovery and control visibility. | |
| Recommendation — Define the software estate and ownership model before reviewing controls. Maintain an accurate software inventory so audit findings stay current. | ||
| NIST SP 800-53 Rev 5 | CM-8 — System Component Inventory | Software audits depend on knowing what software is present and approved. |
| Recommendation — Keep a current component inventory to support software audit evidence. | ||
| ISO/IEC 27001:2022 | A.5.9 — Inventory of information and other associated assets | Software audits rely on knowing which software assets exist and who owns them. |
| Recommendation — Maintain an up-to-date software asset inventory and ownership record. | ||
Practitioner Guidance
Why practitioners should care: The value of a software audit comes from what happens after discovery. Findings should feed ownership assignment, rationalisation decisions, and control remediation, otherwise the review becomes a static report that quickly loses value.
Governance implication: Treat the audit as a control process, not a spreadsheet exercise. The most important output is a current, defensible view of what is approved, who owns it, and what should be retired or reviewed next.
Practitioner takeaway: A useful software audit is one that can be repeated, challenged, and acted on without relying on tribal knowledge.
