research
Auditing who can approve a new SaaS purchase
A method for comparing written purchasing authority with the people who actually approve new software, including the exceptions that create duplicate tools and unowned spend.
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
A new software tool often enters a company through a helpful manager with a credit card rather than through a purchasing decision. The written policy may name a single approver, while the practice shows several people approving similar tools with different terms. This study describes how to compare the documented purchasing authority with the approvals that actually happened. The result is a short list of exceptions and a clearer rule for the next purchase.
Question and scope
This study asks who is approving new software purchases, whether those approvals match the written authority, and where the same need is being met by more than one tool. The unit is one purchase or subscription request, and the population is the software purchases made or renewed during a declared quarter. The result describes that company and period, not the ethics of any individual approver. Freeze the quarter and the definition of a new purchase before collecting data.
Include purchases made on a company card, a personal card later reimbursed, and a department budget transfer. Exclude hardware, professional services, and renewals of tools already in the inventory. Record the source of each record so a reviewer can find the original approval. A purchase that never produced an invoice should still be counted if a subscription is active. Record the subscription identifier so the same tool is not counted twice under two invoices.
Define the approval event
An approval is the recorded decision that authorizes the spend, not the moment the card was charged. Define what evidence counts, such as a ticket approval, an email from the budget owner, or a signature on an order form. Record the approver's name and role at the time of the decision. A verbal approval that cannot be evidenced should be marked as unverified rather than assumed.
Decide how to treat a purchase that was approved after the charge. Late approval is still an exception worth recording, because it shows the control ran in the wrong order. Record both the charge date and the approval date. The gap between them is a useful measure of how often purchasing authority is applied after the fact. Report the median gap and the longest gap rather than only the average.
Map the written authority
Collect the current purchasing policy, the delegation of authority, and any software-specific rules. Write down who may approve what amount, which roles must be consulted, and where security or privacy review is required. Note the version and date of each document. A policy that cannot be dated is hard to apply to a past purchase.
Compare the documents with each other, because the finance policy and the IT policy often disagree about software. Record the conflict rather than choosing one silently. Ask the owner of each document which rule should prevail. The audit should surface the ambiguity that managers are already navigating. Ask the policy owners to agree on one interpretation before the findings are published.
Build the purchase frame
Export the vendor, the tool, the amount, the billing period, the cost centre, the requester, the approver, and the approval date. Link each purchase to the subscription record and to any security review. Reconcile the count with the accounts payable ledger and explain any difference. A purchase that appears in the ledger but not in the request system is an approval gap.
Group similar tools by function so duplicate spend becomes visible. A company may pay for three project trackers because each team solved the same need separately. Record the function and the owner for each tool. The grouping turns a long purchase list into a small number of decisions about consolidation. Keep the function labels stable so the next audit can compare the same groups.
Compare policy with practice
For each purchase, record whether the approver had the authority described in the policy. Mark the case as compliant, exceeded authority, missing approval, or unclear. Use a short evidence note for each classification. Report the counts beside the total, not as a single percentage that hides the exceptions.
Look for patterns by department, amount, and tool type. A department with many small exceptions may have a process that is too slow for its needs. A single large exception may be a one-off decision that deserves a retrospective approval. The pattern matters more than the total because it points to the fix. Show the pattern by department and by amount band in the appendix.
Test the edge cases
Review purchases just below an approval threshold, free tools that later converted to paid, and tools bought through a marketplace. These are the cases where the policy is most likely to be bypassed without anyone noticing. Check whether the marketplace purchase created a subscription the finance team cannot see. Record the finding even when the amount is small.
Check purchases made during a holiday or a staff transition, because approvals are often compressed or skipped then. Confirm whether a backup approver acted and whether that authority was documented. A temporary arrangement that repeats every quarter is not temporary. The edge cases usually show where the written policy needs a clearer path. Record the approver's understanding of the rule, because ambiguity is a finding too.
Report exceptions by risk
Rank the exceptions by data sensitivity and annual spend rather than by the size of the single charge. A low-cost tool that holds customer records carries more risk than an expensive tool with no company data. Show the annualized cost and the data category for each exception. The owner can then decide which cases need action first.
Separate the exceptions that need a policy change from those that need a conversation with an individual. A repeated pattern across a department is a design problem, while a single unapproved purchase may be a training issue. Recommend the smallest change that addresses the largest group. Avoid proposing a new approval layer for every tool. A single threshold change is easier to test than a full policy rewrite.
Recommend a shorter path
Design a fast approval route for low-cost, low-risk tools that still records the decision and the owner. A path that takes two days will be bypassed, while one that takes two weeks will be avoided. Set a clear threshold and a short security checklist for the low-risk route. The control should be easier than the workaround.
For higher-risk tools, name the reviewers and the expected turnaround. Publish the criteria so requesters know why a tool needs a deeper review. Record the decision and the conditions, such as a data processing agreement or a limit on stored data. A predictable process reduces both shadow purchasing and unnecessary delay. Publish the expected turnaround so requesters can plan around it.
Limits and next use
The audit measures purchases that left a record and approvals that can be evidenced. It does not capture tools bought entirely outside the company's visibility, such as a free tier used with a personal account. It also cannot prove that an approver understood the risk. State those limits so the result is not treated as a complete inventory of spend.
Repeat the audit after the approval path changes and compare the same exception categories. If the number of missing approvals falls but duplicate tools rise, the new path may be too permissive. The next study should add a short review of the tools that were declined to see whether requesters found a workaround. A control is only effective when the alternative is not easier. Keep the declined-tool list small and review it for a pattern of unmet needs.
Recheck after the change
Run a small follow-up sample three months after the new path is introduced. Check whether low-risk purchases use the fast route and whether high-risk purchases receive the required review. Ask a few requesters what they would do differently. Their answer is a practical test of whether the process is usable.
Record the results in the same format as the first audit so the comparison is direct. If the exceptions move rather than disappear, investigate the new route before adding more rules. Keep the policy owner and the finance owner in the review. The goal is a purchasing process that people follow because it works, not because it is enforced. Report the follow-up result to the same owners who saw the first audit.
Sources and next step
Use the NIST Cybersecurity Framework 2.0 and the CISA Cross-Sector Cybersecurity Performance Goals as primary references for the identity, asset, and vendor 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 asset record accuracy study and the account provisioning lead time study 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 who can approve a new saas purchase 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 who can approve a new saas purchase, 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 |
|---|---|---|
| Audit window | 1 quarter | Study protocol |
| Exception types | 4 | Study protocol |
| Review levels | 3 | Study protocol |
Sources
- NIST Cybersecurity Framework 2.0Governance and supply-chain outcomes for software acquisition.
- CISA Cross-Sector Cybersecurity Performance GoalsPractical vendor and access goals for small organizations.
- NIST SP 800-53 Rev. 5Acquisition and access control requirements for purchased services.
- GAO Assessing Data ReliabilityEvidence and reconciliation checks for purchase records.
- U.S. Small Business AdministrationSmall-business guidance on vendor and data risk.
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