A former employee still has access to a contract platform. A finance team is paying for duplicate project-management tools. A critical SaaS application sits outside single sign-on, with no named business owner. These are not isolated housekeeping issues. They are common control gaps with security, continuity and cost implications. Knowing how to audit SaaS access gives IT and business leaders a practical way to regain visibility without obstructing the teams that rely on cloud software to do their jobs.
The objective is not to remove applications indiscriminately. It is to establish which services the organisation uses, who can access them, what level of access they hold and who is accountable for each one. That creates a more defensible security position and a clearer basis for renewal, procurement and incident response decisions.
Start with the business question, not the application list
An effective audit begins by agreeing what decision the organisation needs to make. For some corporate environments, the immediate concern is leavers retaining access. For others, it is unmanaged SaaS spend, third-party data exposure, or preparation for a client security review.
Set the scope before collecting data. Include production business applications, departmental tools, browser-based services purchased on company cards and systems used by suppliers where they process corporate information. Do not assume Microsoft 365 or an identity platform provides a complete view. Single sign-on can reveal a great deal, but applications accessed with standalone credentials, personal sign-ups or shared accounts often sit outside it.
For an initial audit, define the following in plain terms: which legal entities and locations are included, what constitutes a SaaS application, who owns decisions on access, and what evidence will be accepted. This prevents the exercise becoming an unstructured hunt for every web service ever used by an employee.
How to audit SaaS access in a controlled sequence
The strongest audits bring together identity data, financial evidence and departmental knowledge. Each source exposes a different part of the picture.
Build a reliable application inventory
Start with identity and security records. Review enterprise applications configured in Microsoft Entra ID, including single sign-on, OAuth consent, service principals and provisioning connections. Security tooling, DNS or secure web gateway logs can help identify cloud services that staff are accessing but which are not represented in the approved catalogue.
Then compare this technical record with finance and procurement data. Supplier invoices, expense claims, purchase orders and renewal calendars often reveal applications acquired outside central IT. Speak with functional leaders in finance, HR, legal, sales, operations and project delivery. They may use specialised services that would not appear in a standard IT asset register.
Record each service in one inventory, even if the information is incomplete at first. A useful record includes the application name, supplier, purpose, department, business owner, technical owner, renewal date, contract route, data classification, authentication method and estimated user population. The inventory is not merely an asset list. It is the working record that turns access findings into accountable actions.
Reconcile people, accounts and permissions
For every application in scope, obtain an export of active users, administrators, guest accounts, groups and service accounts where the supplier makes this available. Compare it with the authoritative HR record and identity directory.
Look first for obvious exceptions: former employees, contractors whose engagement has ended, duplicate identities, dormant accounts and shared logins. Shared administrator accounts deserve particular attention because they weaken accountability and make investigation harder. There can be operational reasons for break-glass or emergency access, but it should be documented, controlled and reviewed rather than simply inherited.
Next, assess privilege. An active account is not automatically a problem; an unneeded administrator, billing administrator, global workspace owner or data-export permission may be. Review roles against actual job responsibilities and use least privilege as the decision principle. A legal team may need access to a matter-management service, for example, but not unrestricted tenant administration.
Where an application supports group-based access and automated provisioning, use those capabilities where appropriate. They can reduce manual joiner, mover and leaver tasks. However, automation is only as reliable as the identity data and role design behind it. Avoid forcing a complex access model into a small specialist application if the vendor cannot support it safely.
Identify accounts outside central identity controls
SaaS platforms that use local usernames and passwords create a different management burden. They are not necessarily unsuitable, but the organisation needs compensating controls. Establish a named owner, require multi-factor authentication where available, define how leavers are removed and keep an access review record.
Also examine applications connected through OAuth. Users may grant a third-party service permission to read mailboxes, files, calendars or profile data without creating a conventional account in the corporate directory. Review consent settings and application permissions in Microsoft Entra ID, then distinguish between approved business integrations and unnecessary or high-risk connections.
This is where security and productivity need balanced judgement. A blanket ban on integrations can disrupt legitimate workflows. A permissive model with no review creates unnecessary exposure. The appropriate position depends on the data involved, the supplier’s role and the organisation’s tolerance for risk.
Prioritise by business impact, not by the longest user list
Not every finding requires the same urgency. Classify applications according to the information they hold and the operational consequence of loss, misuse or unavailability. An application containing client documents, payroll information, commercial terms or privileged legal material warrants closer scrutiny than a low-risk collaboration tool with no sensitive content.
Consider four practical factors together:
- The sensitivity and volume of data held or processed.
- The privileges available to users and administrators.
- Whether the service is critical to revenue, client delivery or core operations.
- The quality of identity, logging, supplier ownership and recovery arrangements.
This approach gives leadership a defensible remediation order. Remove access for leavers and excessive administrators promptly. Then address applications with unclear ownership, weak authentication or sensitive data outside agreed controls. Lower-risk duplication or unused licences can move into a planned commercial review.
Do not confuse a vendor’s native retention features with an independent recovery strategy. If a SaaS platform is business-critical, the audit should establish what recovery options exist, who can initiate them and whether they meet the organisation’s requirements. Retention, deletion protection and backup are related but different controls.
Assign ownership that survives organisational change
A SaaS access audit often exposes a governance problem rather than a technical one: nobody is clearly responsible for a system once the original sponsor changes role or leaves.
Every material application should have a business owner and a technical or service owner. The business owner confirms that the application remains necessary, approves access for the relevant function and makes renewal decisions with procurement. The technical owner oversees identity integration, configuration standards, support routes and security requirements. In smaller teams, one person may hold both roles, but the responsibilities should still be explicit.
Set a review cadence based on risk. High-impact systems may need quarterly checks, while lower-risk applications may be suitable for a six or twelve-month review. Trigger reviews after mergers, restructures, major supplier changes, incidents or changes to the data processed. A spreadsheet can support an early-stage programme, but repeatable evidence, approval records and automated deprovisioning become more valuable as the application estate grows.
Turn findings into an operating process
The audit should finish with an action register, not a static report. For each finding, document the required action, accountable owner, due date and evidence of completion. Typical actions include disabling accounts, replacing shared credentials, reducing privileged roles, assigning an owner, consolidating duplicate services or bringing an application into formal procurement and security review.
Make access governance part of normal operations. Tie SaaS access into joiner, mover and leaver processes. Require application owners to confirm access periodically. Include SaaS systems in incident response plans and supplier reviews. Procurement should know when a new tool requires identity integration, data protection assessment, commercial approval or a recovery plan before it is introduced.
For international organisations, the process must also account for local entities, data handling obligations and regional support arrangements. The principle remains consistent: visibility, accountable ownership and proportionate controls. The implementation details should reflect the organisation’s structure rather than a one-size-fits-all template.
WestTech can help corporate IT teams assess their SaaS estate, strengthen identity and access controls in Microsoft cloud environments, and define a manageable operating model for ongoing reviews. A focused service enquiry can start with the applications that present the greatest operational or security concern, then expand into a wider governance programme where required.
A useful SaaS access audit should leave the organisation with more than fewer accounts. It should make the next access decision easier, faster and clearly owned.
