Back to lesson

Vendor Risk Management

Slide 1: Vendor Risk Management

On-screen

Vendor Risk Management

Protecting continuity and security

Narration

Anna: Every vendor you sign becomes part of your service, whether or not your customers know their name.
Greg: Which means their outage is your outage, their breach is your breach, and their financial trouble eventually becomes your migration project.
Anna: So vendor risk management is really about two questions. What happens if they fail, and how quickly could you leave?
Greg: We'll work through continuity planning, financial exposure, the dependencies you may not have mapped, and what to check before you sign rather than after.

Slide 2: Why worry about vendor lock-in?

On-screen

Why worry about vendor lock-in?

Vendor lock-in happens when switching away from a service becomes expensive or

technically difficult. Imagine all your files saved in a format that only one

vendor's software understands. Changing providers might require costly data

conversions or lengthy downtime, so the vendor holds all the power. Real-world

examples range from custom Salesforce integrations that won't export cleanly to

cloud platforms with no easy migration path. Warning signs include contracts

with 12‑month notice periods, proprietary data formats, or ongoing integration

fees that grow over time. It's like dating someone who slowly moves all your

stuff to their place—leaving suddenly becomes a major project. Always ask,

"How do we get our data out if we need to leave?" up front and negotiate

reasonable exit clauses before signing anything.

Narration

Anna: Vendors make bold promises, but what happens when they change
pricing or disappear entirely? If your whole service depends on them, even a
minor hiccup can snowball into a major disruption.
Greg: Exactly. Risk management is about preparing for those "what if"
moments before they happen so you're not left scrambling. We'll break down
vendor lock-in, data security, business continuity and a few other gotchas that
often get overlooked.
Anna: Think of it as disaster planning for external relationships. The more
you understand potential pitfalls, the easier it is to negotiate contracts and
set expectations from the start. Ready to dig in?
Greg: Let's do it.

Slide 3: Safeguarding data security

On-screen

Safeguarding data security

Handing over data to a vendor is like giving someone the keys to your house.

You want to know their locks are strong and they actually monitor who comes and

goes. Ask about encryption both in transit and at rest, and check whether staff

undergo background checks before they can access your information. Find out

where servers are located because privacy laws differ around the world. Don't be

shy about their breach history—have they ever disclosed incidents and how long

did notification take? A reputable vendor will gladly provide documentation such

as SOC 2 or ISO 27001 certifications and will outline their incident response

process. If they dodge questions or claim "trust us," that's a red flag. Asking

about security shouldn't feel like interrogating a spy; if they're evasive,

that's your answer right there.

Narration

Anna: "Vendor lock-in" means it's painfully difficult to move your data or
workflow somewhere else. Think about a car that only runs on fuel from one
specific gas station chain.
Greg: The longer you rely on their proprietary format, the more trapped you
become. I've seen companies spend six months and $50,000 just to migrate their
customer databases to a new CRM.
Anna: That's why you negotiate export capabilities and reasonable notice
periods up front. Ask to see an export demo during the sales process, not after
you've signed a contract.
Greg: When switching is possible before you need to switch, you keep the
power in the relationship instead of the vendor.

Slide 4: Business continuity planning

On-screen

Business continuity planning

Every vendor will claim they have backups, but have those backups ever been

restored in a real emergency? Ask to see test results or drills where the vendor

simulated a failure and recovered systems. Business continuity also means

thinking beyond a single provider. Maintain a secondary supplier or at least a

clear exit clause so you can pivot if their service goes dark. Map out

escalation paths for different severities—who do you call if the service is down

for an hour versus a day? Having a well‑practiced plan keeps you operating when

surprises strike, just like carrying an umbrella even when the forecast looks

sunny.

Narration

Anna: Every vendor claims they have backups. The useful question is whether those backups have ever been restored under pressure.
Greg: Ask to see test results, or notes from a drill where they simulated a failure and actually recovered. A backup nobody has restored is a hypothesis.
Anna: Continuity also means thinking past a single provider. Keep a secondary supplier in mind, or at minimum an exit clause that lets you move if the service goes dark.
Greg: And map escalation by severity. Who do you call when it's been down an hour, and who do you call when it's been down a day? Those are usually different people.

Slide 5: Financial risk assessment

On-screen

Financial risk assessment

  • Analyse licensing models carefully: is pricing based on users, data volume or something else entirely?
  • Watch for per-seat pricing that looks cheap at 10 users but explodes to $50K at 500.
  • Factor in currency swings and automatic renewal clauses that increase fees annually.
  • Weigh the stability of startups versus established firms—one may cost less but carry higher risk.
  • Case study: one firm spent $200K migrating from Oracle to PostgreSQL after licensing fees spiked.
  • Thorough financial reviews early on prevent nasty surprises later.

Narration

Anna: Start with the licensing model. Is the price driven by users, by data volume, or by something you haven't measured yet?
Greg: Per-seat pricing is where this bites. It looks cheap at ten users and becomes fifty thousand dollars at five hundred, and nobody models that in advance.
Anna: Factor in currency movement and automatic renewal clauses that step the fee up every year.
Greg: Then weigh stability. A startup may quote less than an established firm while carrying more risk of disappearing.
Anna: One firm spent two hundred thousand migrating from Oracle to PostgreSQL after fees spiked. The migration was the cheap option by then.

Slide 6: Operational dependencies

On-screen

Operational dependencies

Relying on a single vendor can create a fragile chain of dependencies. If their service goes down, do your internal processes grind to a halt? Consider how long it would take staff to learn a replacement system or rebuild integrations. A real-world outage, like Slack's six-hour downtime in 2021, left many teams scrambling because chatbots and help desks all flowed through a single tool. Document alternative workflows—when Slack is down, teams might revert to email threads and phone trees—and build training time into your budget so switching providers doesn't paralyse your organisation.

Narration

Anna: Leaning on a single vendor builds a chain of dependencies that can be surprisingly fragile. If their service stops, do your internal processes stop with it?
Greg: When Slack went down for six hours in 2021, plenty of teams discovered that their chatbots, their help desk and their escalation paths all ran through one tool.
Anna: So document the alternative workflow before you need it. If chat is down, do people fall back to email threads and a phone list, and does anyone know that?
Greg: Also budget the learning time. Switching providers isn't just a migration cost, it's weeks of people being slower at their jobs.

Slide 7: Legal and compliance considerations

On-screen

Legal and compliance considerations

Data sovereignty laws and industry regulations can dictate where and how vendor services operate. Ensure that contracts spell out who owns the data, how it may be used and what liability the vendor carries if they breach privacy or security requirements. Ask about compliance certifications relevant to your sector. For example, healthcare providers must verify HIPAA compliance before putting records in the cloud, while retailers may need PCI DSS for payment details. Some jurisdictions require your data to remain in-country, so confirm server locations and backup storage. Insurance coverage and indemnity clauses also play a role; they define who pays if things go wrong. Understanding these legal obligations up front reduces headaches later.

Narration

Anna: When you hand over data to a vendor, it's like giving someone the keys to your house.
Greg: Right, and it's like a friend borrowing your car—you want to know they have insurance and won't lend it to their teenager. Ask about encryption both at rest and in transit.
Anna: Don't forget access controls. If anyone at the vendor can peek at your information, that's a problem.
Greg: A mature vendor will show you compliance certificates and walk you through their incident response plan. If they get hacked, how quickly will they tell you?
Anna: And check their history. A breach isn't always a deal breaker, but silence or slow notifications definitely are.

Slide 8: Due diligence checklist

On-screen

Due diligence checklist

  • Evaluate financial stability and customer references
  • Review security certifications and audit reports
  • Test data export options before signing

Narration

Anna: Before signing, three checks that catch most problems. Look at financial stability, and actually call the customer references rather than reading the case study.
Greg: Ask the references what went wrong, not whether they're happy. Everyone is happy in a testimonial.
Anna: Second, review the security certifications and audit reports, and check what scope they cover. A SOC 2 for a different product line doesn't help you.
Greg: And third, test the data export before you sign, while you still have their attention. Finding out that export is a paid professional services engagement is a discovery best made early.

Slide 9: Red flags during selection

On-screen

Red flags during selection

  • Evasive answers about pricing or compliance
  • No references or vague case studies
  • Unrealistic implementation timelines

Narration

Anna: Some warning signs show up during selection, and they're consistent.
Greg: Evasive answers about pricing or compliance. If a straightforward question about their certification produces a meeting invitation instead of an answer, that's the answer.
Anna: No references, or case studies vague enough to describe any company. A vendor with happy customers is usually keen to introduce you.
Greg: And unrealistic implementation timelines, which are the most seductive of the three, because the optimistic date is exactly what you want to hear.
Anna: Any one of these is worth a direct question. Two together is worth a second candidate.

Slide 10: Exit strategy planning

On-screen

Exit strategy planning

  • Negotiate clear termination clauses and notice periods
  • Document data migration steps and associated costs
  • Keep alternative vendors in mind in case you need to switch

Narration

Anna: Plan the exit while you're still negotiating, because that is the only moment you have leverage.
Greg: Negotiate clear termination clauses and notice periods. A hundred and eighty days' notice sounds harmless until you're six months into a service you want to leave.
Anna: Document the migration steps and what they'd cost, in enough detail that someone could act on it. Data formats, integration rebuilds, retraining.
Greg: And keep a sense of who the alternatives are, even when things are going well. The point isn't distrust. It's that a company with somewhere else to go negotiates differently at renewal.

Slide 11: Key takeaway

On-screen

Key takeaway

  • Ask about data export options before signing
  • Verify security certifications and test backups
  • Schedule regular reviews to keep risks visible
  • Document who owns each vendor relationship internally
  • Hold a quarterly risk review to track emerging issues

Narration

Anna: Business continuity is your lifeboat when a vendor hits rough seas.
Greg: Backup plans are like fire drills—they only work if you've actually practiced them. Ask for proof that their backups actually work—a written plan is meaningless if they've never restored from it.
Anna: Some companies schedule practice runs where they simulate a complete outage and measure how quickly systems come back online. That's the kind of evidence you want.
Greg: Also think about dependencies. If your vendor goes down, do you have a secondary provider, or at least an exit clause that lets you bring operations in-house?
Anna: Having these options ahead of time turns a potential disaster into a temporary inconvenience.