Every vendor will tell you they’re committed to security. They take it very seriously. They’re a trusted partner in your security journey. They understand your challenges and they’re here to help.

None of this means anything.

I’m not saying vendors are malicious. Most aren’t. But they’re businesses with business objectives, and those objectives aren’t perfectly aligned with yours. They want to sell you products, expand their footprint in your organization, and minimize their liability. You want tools that work, reliable service, and transparency when things go wrong.

Those aren’t the same thing.

Understanding this dynamic—and adjusting your expectations and processes accordingly—is critical. Because you’re going to rely on vendors for critical infrastructure and applications, and if you approach those relationships with naive trust instead of informed skepticism, you’re going to get burned.

The Marketing vs. Reality Gap

Vendor marketing materials are aspirational, not descriptive.

“Enterprise-grade security.” What does that actually mean? Depends on the vendor. Might mean they encrypt data at rest. Might mean they have SOC 2. Might mean they did a penetration test once. It’s a phrase that sounds impressive and commits them to nothing specific.

“Comprehensive audit logging.” We talked about this in the visibility post. Comprehensive to them might mean they log authentication. You need data access events? That’s a different tier. You need API call logs? That’s custom pricing. You want real-time log forwarding to your SIEM?

Oh, they don’t support that. But there’s an Excel export you can run manually. Once a day. During business hours.

So much for your real-time security monitoring.

The gap between what the marketing promises and what the product actually delivers can be significant.

“24/7 support.” Sure, you can open a ticket anytime. Whether anyone actually looks at it in a timely fashion is a different question. And here’s where you need to read the SLA carefully—because “24/7 support” might mean they’ll acknowledge your ticket within 24 hours, not that they’ll actually start working on it. Acknowledgment and resolution are very different things, but the sales deck doesn’t make that distinction. (We’ll get into SLA definitions more in a minute—they’re worth understanding before you need them.)

“Seamless integration.” It integrates with your environment using documented APIs and standard protocols. Whether that integration actually works smoothly, whether it requires custom scripting, whether it breaks when either system updates—that’s the reality you discover after purchase.

The sales process is about showing you the best-case scenario. Your job is to figure out what the realistic scenario looks like.

Due Diligence That Actually Matters

Most vendor security assessments are theater.

You send them a questionnaire with 200 questions about their security practices. They send back answers that were written once and are used for every customer. “Yes, we encrypt data in transit and at rest.” “Yes, we perform regular penetration testing.” “Yes, we have an incident response plan.”

None of this tells you anything useful.

And here’s another problem: vendors redefine common industry terms to mean whatever their product actually does.

They say ‘multifactor authentication.’ You’re thinking MFA app, hardware token, something actually secure. They mean username and password, plus we’ll email you a code—or worse, SMS.

Email is explicitly prohibited by NIST SP 800-63B-4 for out-of-band authentication. It doesn’t prove possession of a specific device and is too vulnerable to compromise.

SMS codes are now classified as a ‘restricted authenticator’ under NIST SP 800-63B-4 (Section 3.2.9). Organizations can still use them, but only if they: offer alternatives, inform users of the risks, implement additional mitigations like monitoring for SIM swaps and device porting, and maintain a migration plan to move away from SMS over time. That’s the 2025 guidance—SMS is tolerated, not recommended, and organizations using it need to acknowledge they’re accepting known risks.

You ask about supporting an authenticator app—maybe the one your entire organization already uses for everything else. “Oh, that’s on our roadmap. It’s too complex to implement right now.” Too complex. Too costly.

But emailing codes? That they can do. That’s simple enough.

They say “network segmentation.” You’re thinking proper isolation with stateful firewalls controlling traffic between segments. They mean separate subnets with no actual access control in between. Traffic flows freely; they just put different IP ranges in different VLANs and called it segmentation.

And sometimes the sales guy is so non-technical—and the sales engineer assigned to help him is barely better—that neither of them can actually answer detailed questions without taking them back to the dev team. You ask about SAML attribute mapping or API rate limits or log retention policies, and you get “let me check with engineering and get back to you.” Which should tell you something about how well this is going to go when you need support.

What you actually need to know:

What access controls exist and how granular are they? Can you implement least privilege or is it all-or-nothing permissions? Can you restrict access by IP, by time of day, by specific actions? Or do you get “admin” and “user” and that’s it?

What logging is actually available and what does it cost? Not what they claim to log—what can you actually export, in what format, with what latency, and is there a separate fee for it? Can you get the logs in real-time or is there a 24-hour delay? Can you export to your SIEM or do you have to use their analytics platform?

What happens during an incident? Not what the glossy incident response plan says—what actually happens? How do you get notified? What information do they provide? How quickly?

Are they transparent about root cause or do they give you vague reassurances? Do they help you determine if your data was exposed or do you have to figure that out yourself?

And here’s a critical one: what does “immediate notification” mean in their contract? Because I’ve seen vendors interpret that as “we’ll notify you after the forensic investigation is complete”—which turns out to be three months after the breach, five months after your data was actually exposed and already circulating in the wild. Their lawyers and your understanding of “immediate” might be very different things.

(The Marquis breach is a recent example of exactly this problem—customers finding out about compromised data through third parties rather than timely vendor notification. I wrote about that here.)

How do they handle vulnerabilities? What’s their patching cadence? How do they notify customers? Do they provide advance notice before making changes that might affect you? If they have a significant security issue, when do you find out—before or after it’s public? (Hint: it’s likely after.)

What are their subprocessors and where is your data going? They’re probably not running everything themselves. What third parties have access to your data? Where is it geographically? Do you have any control over that? Some vendors are transparent about this. Others you have to push to get answers.

What’s the data retention and deletion policy? When you delete something, is it actually deleted or just hidden from your view? When you terminate service, how long until your data is actually removed from their systems? Can you verify deletion happened?

And here’s one that almost nobody asks: what happens during their disaster recovery testing? Can your “deleted” data be accidentally restored from a DR backup during a test or actual recovery event—and then just sit there because someone forgot to re-delete it?

You got a certificate of destruction when you terminated the contract. That should mean something, right? Except now your data is back in their environment because of a DR restore, and nobody on their ops team knows it’s supposed to be gone. Because that happens.

Ask specific questions. Push for specific answers. “We take security seriously” isn’t an answer.

SLAs Are Not What You Think They Are

Service Level Agreements sound protective. The vendor commits to certain uptime, response times, support levels. If they don’t meet those commitments, you get… credits.

Service credits don’t help you when your business-critical application is down and costing you revenue. They don’t help you when a security incident happens and you can’t get answers from the vendor. They don’t compensate you for reputational damage or regulatory penalties.

Read the SLA carefully. The uptime commitment probably excludes “scheduled maintenance” (which might be announced with 24 hours notice at their discretion). The response time probably measures when they acknowledge your ticket, not when they actually resolve it. The support commitment probably has exclusions for issues caused by “customer misconfiguration or misuse” (defined however they want).

And here’s a question: can you even see the closure codes the support technician uses when they close your ticket? Because if they mark it as “customer error” or “working as designed,” that ticket doesn’t count against their SLA—even if the issue was absolutely on their side. You might not even know they blamed you for it unless you specifically ask for the closure reason. And good luck disputing it after the fact.

And the remedies are usually capped at a small percentage of your monthly fees. So if they have a major outage that costs you significant money, your remedy is getting back a fraction of what you paid them that month.

I’m not saying SLAs are worthless. But they’re not protection. They’re a contract term that establishes minimum expectations and limited remedies. Treat them accordingly.

The Support Reality

Vendor support quality varies wildly, and you often don’t know what you’re getting until you need it.

Tier 1 support is usually reading from scripts. “Have you tried turning it off and on again?” “Have you checked the documentation?” They’re there to handle common issues and escalate everything else. If you have a complex technical question or a security concern, you’re going to spend time with tier 1 before you get to someone who can actually help.

Higher tiers of support usually require higher-priced plans. “Enterprise support” costs more. “Priority escalation” costs more. “Dedicated support engineer” definitely costs more.

And what does “dedicated” actually mean? Are they supporting just you? Or are they “dedicated” to five customers? Ten? Fifteen? With the hope that not all of you call at the same time? The vendor’s definition and your expectation might not align.

Is it worth it? Depends on how critical the service is and how much risk you’re willing to accept. If the vendor going down means your business stops, you probably need the expensive support tier. If it’s a nice-to-have tool, maybe you can live with slower response.

But understand that support quality is variable. Sometimes you get someone who really knows the product and can help you. Sometimes you get someone who’s reading documentation you could have read yourself. This is true of every vendor—even the expensive enterprise ones.

Here’s something practical: as your team engages with vendor support, document the questions they ask and the exact process they follow. You’ll quickly discover they’re reading from a script. That’s not a criticism of the support person—that’s literally their job. So learn the script.

Know what they’re required to ask. Have the answers ready. Understand what the escalation triggers are. I’ve seen this turn a one-hour initial troubleshooting call into 20 minutes, because I already had the information they needed to check their boxes and move to the next step. It saves time. It saves sanity. And it gets you to someone who can actually help faster.

The Update and Change Problem

Vendors are going to update their products. New features, bug fixes, security patches. You generally want this—products should improve over time.

But vendors update on their schedule, not yours. And sometimes those updates break things.

SaaS products are particularly tricky here. You don’t control when updates happen. The vendor pushes an update, and now you’re running a new version whether you wanted to or not. If that breaks an integration or changes behavior you depended on, too bad.

And depending on the vendor’s DevOps maturity, “updates” might mean a developer created a feature request, pulled the code, edited it, maybe ran some automated tests, and pushed it straight to production. Problem solved for the one customer who asked for it. Problem created for two others who depended on the old behavior. That’s not a theoretical concern—that’s reality at immature organizations masquerading as modern SaaS providers.

Responsible vendors give advance notice. “We’re changing this API endpoint on this date.” “This feature is being deprecated in 90 days.” That gives you time to adapt.

But here’s the problem: who’s actually getting those notifications? Is it going to a shared mailbox nobody monitors? Is it going to the person who set up the integration three years ago and doesn’t work there anymore? And even if the right person gets it, do they understand what they’re reading? Do they comprehend the downstream impact?

Change notifications aren’t business-as-usual “thanks for the FYI” emails. You need to make sure someone on your side—ideally the business owner of that integration—actually reads these things and understands whether it’s “small change, thanks for the heads up” or “oh crap, this is going to break our critical integration and we have 90 days to fix it.”

Less responsible vendors just make changes. You find out when something stops working. And then you’re scrambling to figure out what changed and how to fix it.

There’s not much you can do about this except build in resilience. Don’t build critical processes that depend on undocumented vendor behavior. Have fallbacks where possible. Monitor for changes. Accept that you’re not in control of the release schedule.

Vendor Lock-In Is Real

Once you’re using a vendor’s platform, switching is expensive.

Data migration is hard. Especially if the vendor doesn’t make it easy to export in a usable format. Especially if you’ve accumulated years of data. Especially if the new vendor’s import process is fragile or lossy.

Integration work has to be redone. All those connections to other systems, all that custom scripting, all that workflow configuration—none of it carries over to a different platform.

Staff knowledge doesn’t transfer. Your team has learned this platform. Moving to a different one means retraining. Means hiring people with different skills or waiting for your current staff to ramp up. Means reduced productivity during the transition.

This isn’t an accident. Vendors know that switching costs keep customers around even when they’re unhappy. So they design products that integrate deeply, that store data in proprietary formats, that require specialized knowledge.

I’m not saying you should avoid vendor products or refuse to integrate deeply. But go in knowing that you’re making a long-term commitment. Switching later will be painful and expensive. Make sure you’re choosing vendors you can actually live with for a while.

The Breach Notification Question

When a vendor gets breached, you need to know. Promptly. With enough detail to assess your risk.

What you actually get depends on the vendor.

Good vendors will notify you quickly—often before the breach is public. They’ll tell you what happened, what data was potentially exposed, what they’re doing about it. They’ll be transparent about the timeline and the scope.

Less good vendors will wait until they’re legally required to notify, hope it doesn’t make the news, and send you a vague letter about “a security incident” without much detail. You’re left trying to figure out if your data was actually affected and what you should do about it.

And some vendors will fight disclosure entirely. Claim it wasn’t actually a breach. Claim no customer data was accessed (even if systems that contained customer data were compromised). Minimize the severity. Only acknowledge what they have to.

This is one of those things you can’t really evaluate during the sales process. But you can include notification requirements in your contract. “Vendor shall notify Customer within 24 hours of discovering a security incident that may affect Customer data.”

Pay attention to the language here. “Shall” and “must” are binding obligations. “Will” is generally binding but slightly weaker. “Should” is advisory—nice to have, but not enforceable. Your vendor’s lawyers know this. You should too.

And if this is a mission-critical application where downtime costs you revenue, or where a breach would trigger regulatory penalties, don’t just hand this language to your legal team in a vacuum. Give them context. Explain why prompt notification matters for this specific vendor relationship. They can’t negotiate effectively if they don’t understand what you’re actually trying to protect.

It’s not perfect, but it’s better than nothing.

The Shared Responsibility Trap

Cloud vendors especially love to talk about shared responsibility. They’re responsible for security “of” the cloud—the infrastructure. You’re responsible for security “in” the cloud—your configurations and data.

This is technically true. But it’s often used to deflect blame.

There’s a misconfiguration that exposes your data. “That’s your responsibility—we provide the controls, you have to use them correctly.” There’s a vulnerability in the platform. “We patched it, but you didn’t enable the security feature that would have mitigated it.”

Sometimes this is fair. If you leave an S3 bucket publicly accessible because you didn’t configure permissions correctly, that’s on you. The controls existed, you just didn’t use them.

Sometimes it’s not fair. If the default configuration is insecure and you have to know to change it, that’s poor design. If the security controls are buried in obscure settings, that’s a UX failure. If the documentation doesn’t clearly explain the risks, that’s inadequate disclosure.

The point is: shared responsibility means you need to understand your part. You can’t just trust that the vendor has secured everything. You have to configure things correctly, enable available security features, understand what your responsibilities actually are.

And when something goes wrong, “shared responsibility” might mean the vendor denies any fault and you’re left holding the bag.

What You Can Demand (And What You Can’t)

You have more leverage than you think during negotiations, but less than you’d like after you’ve signed.

Before you sign, you can negotiate contract terms. Data location requirements. Security requirements. Audit rights. Notification timelines. Indemnification. Data deletion procedures. Not every vendor will agree to everything, but many will agree to some things, especially for larger contracts.

Watch out for vendors who subtly change words during negotiation. You propose language with “shall.” The redline comes back with “should.” You ask for “will notify within 24 hours.” They counter with “will make reasonable efforts to notify.” This isn’t accidental. These word changes fundamentally alter who’s responsible and what’s enforceable. If you let them slide, you’ve just given up your leverage.

And here’s a major red flag: you ask to include something specific in the contract, and the vendor says “oh, we don’t need to put that in writing—that’s just our standard practice” or “that’s basic customer service, we always do that.”

No. If it’s important enough for you to ask for, it’s important enough to write down. If they actually do it as standard practice, then writing it down shouldn’t be a problem. The fact that they’re resisting putting it in the contract tells you they want the flexibility to not do it when it’s inconvenient. Get it in writing.

After you sign, your leverage is limited. You can escalate issues. You can threaten to leave (which they know is expensive and time-consuming for you). You can leave negative reviews or tell your peers. But fundamentally, the contract you signed is what you have to work with.

So get it right up front. Don’t assume you can fix contract problems later. Don’t accept vague language hoping you can interpret it favorably. Get specific commitments on the things that matter to you.

And know your deal-breakers. If a vendor won’t commit to reasonable security practices or transparency, that tells you something. Maybe they’re worth the risk anyway because they’re the only option for what you need. But at least you know what you’re getting into.

The Realistic Approach

You’re going to use vendor products. You don’t have a choice. Building everything in-house isn’t realistic for most organizations. And even if you wanted to, buying software to install on your own infrastructure is rapidly disappearing. SaaS is the model now.

The goal isn’t to avoid vendors. The goal is to manage vendor risk intelligently.

A note on scope: These patterns apply whether you’re buying SaaS tools, outsourcing SOC functions, or working with managed service providers. The incentive misalignment is structural. A vendor selling you a SIEM, an MDR provider monitoring your environment, a penetration testing firm doing annual assessments, a managed IT services company handling your infrastructure—they’re all businesses with business objectives that aren’t perfectly aligned with yours. The specifics vary, but the underlying dynamic is the same. Understand it and adjust your approach accordingly.

Do real due diligence. Ask specific questions. Test answers. Talk to existing customers if possible—and don’t just talk to their hand-picked reference accounts. Find the customers they don’t want to put in front of you. Those conversations will tell you what actually happens when things go wrong. Don’t just trust the marketing.

Get security and privacy commitments in the contract. Don’t rely on verbal assurances or marketing materials.

Plan for failure. What happens if the vendor has an outage? What happens if they get breached? What happens if they go out of business? Have answers.

Monitor vendor security posture over time. Things change. A vendor that was secure last year might have degraded. A vendor with good practices might have been acquired by someone with worse practices.

Document everything. Issues, concerns, failures, support response times, outages, security incidents. Keep that documentation. When it comes time to renew the contract, this is valuable leverage. You can push for improved SLAs, better service commitments, or reduced pricing based on documented performance problems. Without documentation, you’re negotiating from memory. With it, you have facts.

Try to build relationships with vendor security and support teams where possible. For smaller vendors or if you’re a significant customer, you might actually get access to people who know your environment. When you need help, having a contact who remembers your setup makes a difference.

But be realistic: for most SaaS vendors, especially the larger ones, you’re not getting that. You’re getting ticketing systems, rotating support staff, and generic email addresses. The person who helped you last month doesn’t work that account anymore. The “dedicated” account manager changes every year.

So focus on what you can control: document your environment thoroughly, keep records of your configurations and integrations, and build internal knowledge so you’re not dependent on vendor institutional memory that doesn’t exist.

And maintain healthy skepticism. Vendors aren’t enemies, but they’re not your partners in the sense of having aligned interests. They’re businesses selling you products and services. Their ultimate goal is to extract money from your company while minimizing their own costs.

If they’re publicly traded, that pressure is explicit—maximize revenue, minimize expenses, hit quarterly numbers. If they’re a smaller SaaS startup whose founders are aiming for acquisition, the goal is highest possible valuation at lowest possible cost. Either way, “investing in security infrastructure” or “building robust support capabilities” competes directly with profit margins and growth metrics.

Understanding these incentives helps explain a lot of vendor behavior. It’s not personal. It’s structural. Treat them accordingly—professionally, but without illusions about the nature of the relationship.

Practical Takeaways

Marketing language means nothing. Push for specific, technical answers about capabilities and limitations.

Due diligence should focus on access controls, logging, incident response, and subprocessor relationships—not generic questionnaires.

SLAs establish minimum expectations and limited remedies. They don’t actually protect you from significant harm.

Support quality varies. Evaluate what tier you actually need based on how critical the service is.

Vendor lock-in is real and intentional. Choose vendors knowing you’re making a long-term commitment.

Shared responsibility means you need to understand and fulfill your part. The vendor won’t do it for you.

Negotiate security requirements before signing. You have much less leverage afterward.

Plan for vendor failures, breaches, and business changes. Hope for the best, prepare for the realistic worst case.

Vendors are businesses with business objectives. Your job is to get what you need from them while managing the inherent risks.

Podcast: Download (Duration: 28:14 — 15.2MB) | Embed

Subscribe to the Cultivating Security Podcast Spotify | Pandora | RSS | More