Internal Software Audit Methodology: A Practitioner's Guide for Enterprise IT

Why Internal Audits Are the Most Underused Compliance Tool

The instinct in most organisations is to treat software audits as something that happens to you, not something you control. Vendor audit notifications trigger reactive responses — legal reviews, data gathering under time pressure, and negotiations from a position of uncertainty about what the vendor will find.

Organisations that approach licensing proactively operate differently. They run internal audits on their own schedule, using the same methodology vendors use in the field. They discover their own exposure before vendors do. They remediate compliance gaps quietly, on their own timeline, and at a fraction of the cost of a contested settlement. When vendor audit notifications arrive — and for most large enterprises they will, from Oracle, IBM, Microsoft, or Broadcom — the organisation enters the process already knowing the answer.

The investment in an annual internal audit programme is consistently justified by the outcome: independent assessments show organisations with mature internal audit programmes achieve compliance settlement outcomes that are 40 to 65 percent more favourable than organisations engaging advisory support only after receiving an audit notification.

Phase One: Scoping and Team Assembly

A software audit is not an IT project. It is a cross-functional compliance activity that requires contributions from IT, procurement, legal, and finance. Establishing the right team composition before beginning is critical to audit quality and defensibility.

Define the Audit Scope

Begin by defining which vendor relationships are included in the current audit cycle. Most large enterprises cannot run comprehensive internal audits across every vendor simultaneously. Prioritise by spend concentration and audit risk — typically, the five to ten vendors with the highest annual licence spend, combined with vendors that have recently announced licensing model changes or have active audit programmes in the market.

Oracle, IBM, Microsoft, SAP, and Broadcom consistently represent the highest audit risk and the highest potential exposure. Any organisation running significant deployments of these platforms should include them in the annual internal audit scope. Vendors running active audit programmes — Oracle's License Management Services, IBM's SWMA compliance activities, Microsoft's CATS reviews — should be included whenever the organisation has a significant deployment.

Assemble the Audit Team

The internal audit team should include an IT representative responsible for discovery and deployment data, a procurement lead with access to contract and entitlement records, a legal or compliance representative for contract interpretation, and a finance representative for cost quantification. For complex platforms such as Oracle Database, IBM sub-capacity, or SAP S/4HANA, the inclusion of a licensing specialist — either an internal expert or an external advisor — is strongly recommended.

Establish roles and responsibilities at the outset. Designate a single audit lead responsible for coordinating workstreams, maintaining the audit log, and producing the final report. This role is essential for audit coherence and should not be shared across multiple stakeholders.

Phase Two: Software Discovery

Accurate discovery is the foundation of any reliable audit. A software audit is only as credible as the completeness and accuracy of the deployment data it is based on. Most organisations discover significant gaps in their existing asset inventory during the discovery phase.

Automated Discovery Tools

Discovery should use automated scanning tools that can enumerate all software instances across on-premises servers, virtual machines, cloud instances, and end-user devices. Major SAM platforms including Flexera, Snow License Manager, ServiceNow SAM, and ManageEngine ServiceDesk Plus provide automated discovery capabilities that can be configured to capture the data points required for major vendor audits.

Configure discovery to capture, at minimum, the product name, version, edition, installation date, and host system specifications for each software instance. For processor-metric software (Oracle Database, IBM PVU products), the discovery must also capture processor type, core count, and virtualisation configuration per host. Capturing virtualisation configuration accurately — hypervisor type, vCPU allocation, physical processor partitioning — is critical for any sub-capacity or virtualisation-based licence metric.

Cloud and SaaS Discovery

Cloud and SaaS deployments present a distinct discovery challenge. Infrastructure-as-a-Service deployments on AWS, Azure, and Google Cloud require review of compute instance configurations, storage allocations, and any bring-your-own-licence (BYOL) deployments. SaaS consumption data requires review of user access logs and entitlement records from the vendor portal, supplemented by HR or identity management data to reconcile active user counts against contracted quantities.

Industry data shows that organisations have accurate visibility of on-premises software approximately 67 percent of the time, cloud instances 64 percent of the time, and SaaS usage only 54 percent of the time. These gaps are where vendor audits most commonly find exposure. Internal audits must specifically target these low-visibility areas.

Interview-Based Discovery

Automated discovery tools miss software that is deployed on isolated networks, air-gapped systems, contractor-managed infrastructure, and shadow IT acquisitions made outside the standard procurement process. Supplement automated discovery with structured interviews of IT team leads, business unit technology contacts, and development team managers to identify deployments that automated tools cannot reach.

Phase Three: Entitlement Review

The entitlement review assembles the complete record of what the organisation is licensed to run, against which the discovery data will be reconciled.

Contract and Purchase Record Assembly

Gather all licence agreements, purchase orders, renewal confirmation documents, and entitlement certificates for each vendor in scope. This includes original purchase agreements, subsequent renewals, amendment letters, order forms, and any vendor-issued licence certificates or entitlement confirmations. For Enterprise Agreements, the programme agreement, the enrolment document, and any product-specific addenda are all required.

For organisations that have been through M&A activity, the entitlement review must also cover licences acquired through acquisition, which may carry different terms, may not have been formally transferred, or may have lapsed following the transaction. M&A licence transitions are among the most common sources of compliance exposure in complex organisations.

Metric Mapping

Each product entitlement must be mapped to its applicable licence metric. This step is frequently where internal audits deliver the most value, because licence metrics are complex, have changed over time, and are applied differently in different deployment contexts.

IBM's sub-capacity PVU metric requires IBM License Metric Tool (ILMT) to be correctly deployed and collecting data in order for sub-capacity licensing to be valid. Without ILMT correctly configured, IBM's full-capacity PVU metric applies to all eligible products — typically resulting in significantly higher licence requirements. IBM's transition from PVU to VPC (Virtual Processor Core) metrics for cloud and containerised deployments has created additional complexity, as the applicable metric depends on the deployment context and the version of the product licenced.

Oracle's processor metric requires that the number of required licences be calculated based on the physical processor count multiplied by the applicable core factor, unless an approved sub-capacity configuration is in place. Oracle's Authorised Virtualisation list determines which virtualisation technologies support sub-capacity licensing — a list that has changed over time and continues to be a source of unexpected exposure in audit scenarios.

Phase Four: Reconciliation and Gap Analysis

Reconciliation matches the deployment data from Phase Two against the entitlement data from Phase Three to produce a compliance position — the gap between what is deployed and what is licenced.

Product-Level Reconciliation

For each product in scope, compare the deployed quantity (expressed in the applicable metric) against the licenced quantity. Where deployment exceeds entitlement, document the gap as a compliance shortfall. Where entitlement exceeds deployment, document the surplus as potential shelfware that may be candidates for removal at renewal.

Product-level reconciliation should be documented at a level of detail sufficient to be explained and defended to a vendor auditor. Maintain a workpaper for each product that records the source of each data point, the metric calculation methodology, and the resulting compliance position.

Exposure Quantification

For any identified shortfall, calculate the financial exposure at current list pricing and at estimated negotiated pricing. List pricing provides the worst-case scenario; negotiated pricing provides a more realistic settlement target. The difference between the two is the negotiation space that a well-prepared audit defence can realise.

Exposure quantification should also consider the time dimension. For compliance shortfalls that have existed for multiple years, vendors may seek back-dated licence fees. Understanding the historical deployment pattern is therefore relevant for any exposure that has existed beyond the current licence term.

Phase Five: Remediation Planning

Where the internal audit identifies compliance gaps, the organisation should develop a remediation plan before any vendor-initiated audit activity begins. Remediation options include purchasing additional licences to cover the shortfall, redeploying or uninstalling software to bring deployment within entitlement, renegotiating licence terms to better match the deployment profile, or restructuring the deployment to comply with available licence flexibility provisions.

The optimal remediation path depends on the strategic importance of the software, the available licence types, and the cost of each option. Remediation planning should consider the upcoming renewal cycle — purchasing additional licences to remediate a compliance gap close to a major renewal allows that purchase to be positioned as advance payment toward the renewal, which frequently yields better pricing than a standalone compliance remediation purchase.

Phase Six: Reporting and Governance

The internal audit must conclude with a formal report that documents findings, exposure quantification, remediation recommendations, and proposed timeline. The report should be presented to senior management — at a minimum, the CIO or CTO and the Head of Procurement — and retained as a confidential document under legal privilege where possible.

Report Structure

A well-structured internal audit report covers the audit scope and methodology, a summary of discovery data and its completeness, the entitlement position by vendor and product, the reconciliation results including any identified gaps and surpluses, a quantified exposure analysis, and prioritised remediation recommendations with timelines and cost estimates. The report should be written to be comprehensible to senior executives who are not licensing specialists, supported by technical appendices for the detailed workpapers.

Ongoing Governance

An internal audit is most valuable as part of a continuous compliance programme rather than a one-time event. Annual internal audits, supplemented by quarterly deployment reviews for high-risk platforms, represent the governance standard for organisations that face material software audit risk. Integrating licence compliance checks into the change management process for new deployments, cloud migrations, and platform upgrades prevents new exposure from accumulating between formal audit cycles.