A familiar scene: someone on your team — usually a department head, often during a busy week — finds a SaaS tool that solves a real problem. Could be a project tracker, a scheduling app, an AI writing assistant, a new e-signature service. They sign up with their work email, click through an OAuth prompt that asks for “access to your Microsoft 365 account” without reading the specifics, and three minutes later your business has a new third-party vendor with a connection into your tenant.
Nobody filed a ticket. Nobody on the IT side reviewed it. And now that vendor has a foothold that the person who created it can’t fully describe.
This is how SaaS sprawl happens at the 10–80 employee businesses we work with across the East Valley — not through bad intent, but through pace. The fix isn’t to slow your team down. It’s to put a structured vetting process in place so that when a new SaaS tool comes up, you can say yes or no in a defensible way, in less than an hour, every time.
The Hidden Cost of Third-Party Risk
When a SaaS integration goes wrong, the breach almost never starts inside your own systems. It starts at the vendor. They get compromised; the attacker uses the integration’s existing access to pivot into yours. By the time you find out, the attacker has been walking through your data for days or weeks using legitimately-granted permissions that nobody is monitoring.
We see the pattern across our verticals. A charter school adopts a new attendance-and-communication tool that asks for read-write access to the Microsoft 365 tenant; six months later the vendor announces a breach, and the school has no documentation of which student records, staff calendars, or shared drives were reachable. A law firm enables a third-party document-review service with broad SharePoint scope and discovers, after the fact, that the access included client matter folders the firm never intended to expose. A manufacturing client adds a quoting tool with an OAuth grant that quietly inherited mailbox-read permissions, and the resulting business email compromise costs more than every other line item on that year’s IT budget combined.
In each case the underlying mechanic was the same: an integration was approved without anyone documenting what data it touched, what scopes it held, or how to revoke it cleanly. A structured vetting process — the same one regardless of whether you’re a 12-person Phoenix law firm, a 50-employee manufacturer in Mesa, or a Gilbert charter school of 200 students — turns that liability into a defensible record. It also makes the eventual conversation with insurance, regulators, or clients dramatically easier.
5 Steps for Vetting Your SaaS Integrations
Below is the process we use with our clients before approving a new SaaS integration. It scales down (a single approved tool for a small practice) and up (a regulated mid-market business onboarding a vendor with HIPAA-covered data flows). The steps don’t change; the depth at each step does.
1. Scrutinize the SaaS Vendor’s Security Posture
Start with what the vendor can show you, not what their marketing page says.
The single most useful artifact is a current SOC 2 Type II report. SOC 2 Type II is an independent audit of how the vendor actually operates over a period of time — not just what their security policy claims. Ask for the report directly; reputable vendors will share it under NDA. If they tell you “we’re working on SOC 2,” that’s an honest answer and lets you weigh the maturity tradeoff. If they go quiet, that’s also an answer.
Beyond SOC 2, look at:
Breach history. A vendor that has been breached and disclosed it transparently is often safer than one that has never said anything publicly — silence is not the same as a clean record.
Time in market. A SaaS company that has been around through a couple of incident cycles has usually built better internal processes than one that launched eighteen months ago.
Subprocessors. Many SaaS vendors are themselves built on top of other SaaS vendors. The one you’re evaluating is only as secure as the weakest of its third parties.
At CTS we document every approved vendor’s security posture in IT Glue alongside the connected scopes and contract details. That way when a vendor gets acquired, has a public incident, or changes their data handling, we already know which of our clients are connected and what to revisit.
2. Chart the Tool’s Data Access and Flow
The OAuth scopes a SaaS tool requests are the actual contract. They are not the marketing copy.
When a SaaS application asks for permission in Microsoft 365 / Entra ID, the prompt usually shows a friendly description (“Read your mail,” “Access your files”). The underlying scope strings are stronger and more specific than that. A scope like Mail.ReadWrite.All does not mean “access your email” — it means “read and write every email in every mailbox in the tenant, including mailboxes the requesting user has no business reading.”
For each new integration, your IT team or partner should be able to answer:
Exactly which OAuth scopes are requested?
Which users or service principals are those scopes granted to?
Is the access scoped down — to a single mailbox, a single SharePoint site, a specific group — or is it tenant-wide?
Where does the data go after it leaves your tenant? What’s the geographic location of the vendor’s storage?
Is data encrypted at rest and in transit, and what’s the key management story?
The principle of least privilege applies the same way it does for human accounts: a SaaS integration should hold the narrowest scope that lets it do its job, and nothing more. Most over-scoped integrations are over-scoped because nobody asked the vendor for a tighter alternative — they exist on the vendor’s side, but they’re not the default.
3. Examine Their Compliance and Legal Agreements
The compliance question depends entirely on what kind of data the integration will touch and what regulations apply to your business. For our Arizona clients, the regimes that matter most are:
HIPAA, for any healthcare practice or business associate. Adding a SaaS tool that will touch Protected Health Information without a signed Business Associate Agreement (BAA) is, full stop, a HIPAA violation. The vendor’s standard Terms of Service almost certainly aren’t a BAA. Ask explicitly.
FERPA, for K–12 schools and any vendor handling student educational records. Many SaaS tools marketed to schools default to broader data collection than FERPA strictly permits; the vendor’s contract is where you control that.
State privacy laws, including Arizona’s data exposure law and (for clients with California-resident customers) CCPA / CPRA. These are evolving quickly; assume your obligations will increase, not decrease.
PCI DSS, for any client processing card data, even at low volume. Most SaaS tools introduce in-scope systems whether they intend to or not.
Beyond regulation, the contract itself matters. Confirm whether the vendor will sign a Data Processing Addendum if you require one. Read the data-deletion clauses — specifically, what happens to your data after termination, and how long the vendor reserves the right to retain backups. Look for unilateral-modification clauses that let the vendor change material terms with thirty days’ notice; for a vendor with deep access to your tenant, that’s a clause worth pushing back on.
4. Analyze the SaaS Integration’s Authentication Techniques
How the vendor authenticates into your environment is at least as important as how secure they are in their own.
The standard you want is single sign-on through your existing identity provider — for the vast majority of our clients, that’s Microsoft 365 / Entra ID. SSO does several things at once: it eliminates an extra password set for your users, it lets you enforce your conditional access policies on the SaaS tool, and it gives you a single revocation point when someone leaves the company.
If a SaaS tool doesn’t support SSO via Entra ID — or charges extra for it as a “premium” feature — treat that as a real flag. The “SSO tax” is one of the most-discussed bad practices in SaaS pricing, and at smaller vendors it often signals a broader pattern of treating security as an upsell rather than a baseline.
What to avoid, regardless of vendor:
Integrations that ask for shared service-account passwords, especially with MFA disabled.
Integrations that require disabling conditional access policies, IP restrictions, or device compliance requirements to function.
Anything that requires you to send the vendor an actual user’s credentials rather than authenticating via OAuth or SAML.
A vendor that supports OAuth 2.0 with proper scope granularity, integrates cleanly with Entra ID, and respects your conditional access policies has thought about security. A vendor that asks for a service account with global admin rights and a static password has not.
5. Plan for the End of the Partnership
Every SaaS relationship ends — through deprecation, replacement, acquisition, or vendor failure. The time to plan the exit is before the contract is signed.
Before you approve the integration, you should be able to answer:
How is data exported at the end of the contract? In what format, on what timeline, and at whose cost?
How is the data deleted from the vendor’s primary systems and backups, on what timeline, and what proof of deletion is provided?
How is the OAuth grant revoked, and what residual access (cached tokens, downstream subprocessors, exported reports) might persist after revocation?
What happens if the vendor goes out of business or is acquired by a company you wouldn’t have chosen?
A responsible vendor will have clear, documented answers to all four. If they don’t, that’s not a deal-breaker on its own, but it’s a flag that they haven’t thought about the exit — which usually means their internal data hygiene during the relationship is also weaker than you’d want.
At CTS we maintain offboarding runbooks in IT Glue for every approved vendor — the specific steps to revoke OAuth grants, export data, validate deletion, and document the closure. Building the runbook at approval time, when the vendor is still motivated to help, is dramatically easier than reconstructing it during a hostile termination two years later.
Build a Fortified Digital Ecosystem
Modern small and mid-sized businesses run on dozens of interconnected SaaS services. The integration surface — the set of vendors with active access into your tenant, your data, and your users’ accounts — is now bigger than your local network ever was. Most of the breaches we respond to don’t start at the firewall; they start at a vendor that nobody documented.
Vetting isn’t about saying no to new tools. It’s about being able to say yes in a defensible way, knowing what you’ve granted, who’s responsible if it goes sideways, and how to unwind the relationship cleanly when the time comes.
If you’re an East Valley business and your last few SaaS tools were approved by someone clicking “Allow” on an OAuth prompt — and nobody on your team can list which vendors currently have what scopes into your Microsoft 365 tenant — that’s the conversation worth having. Contact CTS for a free assessment, and we’ll walk your existing integrations together before the next one goes in.
