· Yair Knijn
The shadow SaaS estate that finance found on the corporate card, not in the CMDB
The finance director signs off on the monthly card reconciliation assuming SaaS visibility is IT's problem. It is a reasonable assumption and a wrong one. The tools your team depends on were not provisioned through a procurement request or a ticket. They were bought on a corporate card by a team lead who needed a transcription tool by Friday, renewing at $29/seat ever since, invisible to every register meant to know they exist.
Here is the uncomfortable sequencing. Shadow SaaS shows up in expense data months before it shows up in a security log, because money moves before traffic does. That makes finance, not the SOC, the first place an unsanctioned app becomes visible. The card statement is your earliest signal.
What the card statement reveals that the CMDB never will
A CMDB records what someone declared and configured. It is a list of decisions. The card statement records what people actually did, a different and more honest list. Zylo's 2025 SaaS Management Index found roughly 51% of SaaS applications in use were brought in without IT's involvement, and that shadow IT is about 34% of the average portfolio while accounting for only 4% of spend. Cheap individually, enormous in count. Gartner has long put shadow IT at 30 to 40% of total IT spend in large enterprises. None of it lives in the CMDB, because nobody filed it there.
The card statement does not hand you the answer cleanly either. The same Zylo data notes about half of software expenses are miscategorized as something other than software, buried under generic merchant names and travel codes. Discovery is a reconciliation job, not a query.
Every shadow app is an unsigned DPA and an unassessed vendor
A transcription tool that touches a customer call is a processor under Art. 28 GDPR. No data processing agreement, no documented sub-processors, no record under Art. 30. If that vendor is breached, the obligation to notify is yours, and "we did not know we used them" is the opposite of a defense. Every line you cannot map to a signed DPA and a vendor risk assessment is a regulatory gap you carry without having priced it. The pattern to flag when you reconcile:
- A recurring charge under
$100/monthto a SaaS merchant with no matching contract on file. - The same tool expensed by three people in three departments, each a separate unmanaged tenant.
- A vendor with no documented transfer mechanism for personal data leaving the EU.
Closing the buy-on-a-card loophole without freezing the business
The instinct is to ban card purchases of software. That fails, because the team lead bought the tool for a real reason and a hard no just pushes the spend somewhere you see even less. The workable control is a fast lane: a merchant-category flag that routes any SaaS charge to a 48-hour review for a DPA and a data-flow note, with a standing pre-approved list so routine renewals do not stall. You are not blocking the buy. You are catching it when money moves, while it is still one charge and not a renewed annual contract.
Reconciling spend, contracts, and data flows in one estate view
This stays broken because the three facts you need sit in systems that do not talk: the card statement in finance, the contract in legal, the data flow in IT. Answering "does this app process customer data, and is it covered" means exporting all three and joining them by hand, the night-before-the-audit exercise nobody finishes. The fix is one record the spend, the contract, and the processing inventory all hang off, so one export answers the question instead of a stitching job.
This is the estate model Spot Suite is built on. Each tenant is a Customer Environment that ties the subscription, the signed agreements, and the data-processing record to one identity, so a shadow charge reconciles against a contract and a DPA in one place rather than three. When finance asks which apps touch customer data and which are covered, the answer is one query. See how it fits on the products overview.