Getting Real Value from Your IT Providers: A Working Guide

IT service providers deliver a broad range of services, from single sign-on authentication like Okta to Infrastructure as a Service platforms such as AWS and Oracle. Good providers reduce the operational load on internal information security and IT teams, and take on functions that are not part of the organization's core business. That frees internal resources for work only your own team can do.

Engaging a third party can also introduce challenges that a proper due diligence process would prevent or address. Before starting the selection of a new IT service provider, or acquiring a new software or system, the organization should be able to answer a few questions internally.

Why do we need to engage an IT provider, or introduce another security tool, platform, or application into our environment? What specific functions will this provider or software perform? Do we already have internal resources performing these functions, and if so, what is the cost-benefit of replacing or complementing those services? What is the value proposition for the organization, and how does it align with our current strategy? How will the effectiveness of the services be measured in the short and medium term?

Once those answers are clear, a practical pre-selection assessment covers the following.

1. Usability. In the AI era, viability matters more than it used to. Model deprecation cycles and vendor pivots move faster than in traditional software. Assess how long the technology being acquired is expected to remain viable before becoming obsolete, and whether the vendor has a track record of orderly upgrades rather than sudden platform changes.
2. Specifications. Ensure that the area requesting the service understands the key deliverables and expected results. What should be non-negotiable in the Service Level Agreement and the contract is an effective starting point for drafting the Scope of Work.
3. Relevance. Determine whether an existing service or provider is being replaced and understand the reasons for doing so. Will a new provider address existing problems or change the current situation for the better? Identify the root causes before moving forward. The requesting area should have a clear business case to justify the investment.
4. Budget and ROI analysis. Identify the total investment required, including expected savings and revenues, as well as losses and costs to be avoided. Non-financial benefits should also be considered.
5. Risk. Evaluate whether a new provider or software may introduce new risks, including security, regulatory, legal, or privacy risks. Data hosting and cross-border data flow belong in this category from the start, not as an afterthought. When risks are identified, assess whether they align with the organization's risk tolerance.
6. Value for money. Request at least two quotes for the service. Research and compare pricing, services, and distinctive features across providers to ensure a competitive and transparent selection process. Look at total cost of ownership, not the headline quote: integration effort, training, ongoing support, and exit costs are frequently excluded from initial pricing. Request SOC 2 Type II reporting where the vendor handles sensitive data.
7. Skills and support. Assess whether engaging a new service or software will require additional support, such as training or a lengthy integration process.
8. Customization. Determine the degree of customization required based on the organization's IT environment and functional requirements.

This is not an exhaustive list. Each organization may need to consider additional questions and factors depending on its context and the strategic implications of the work in scope.

That covers selection. Selection is only the first phase of the relationship. The phases that follow are where value is either captured or quietly lost.

Onboarding is where value is won or lost

The contract must define the scope, the data the vendor may access, and your exit rights. The SLA must define what "up" actually means, how availability is measured, what the vendor owes you when it drops below the committed level, and how a service credit is claimed. Monitoring is not an annual invoice check. A quarterly business review with the vendor, against the metrics in the SLA, is the minimum discipline for any provider with meaningful access to your environment.

For AI providers specifically, the contract should also address what happens to model outputs, fine-tuning data, and any embeddings your organization has generated, if and when you leave the relationship.

Where does your data actually live, and whose laws govern it

Ask the vendor three questions in writing before you sign. Where is data stored at rest? Where is it processed? Are any subprocessors in a different jurisdiction, and which ones?

A short example: a Canadian company using a US-hosted AI service means customer data crosses under PIPEDA on the client side and the US CLOUD Act on the vendor side. Both matter when responding to a data subject request or a legal request for records. The same principle applies to Latin American data hosted in the United States or Europe. The point is not to avoid these arrangements. The point is to know where you stand before signing, so the answer to "who can compel access to our data" is never a surprise.

What happens when things go wrong: RPO and RTO in plain English

Two commitments belong in every third-party contract where the vendor holds or processes business-critical data.

Recovery Point Objective, or RPO, is how much data you can afford to lose, measured in time. One hour of transactions? Twenty-four hours? The answer depends on the business, not on what the vendor is willing to offer.

Recovery Time Objective, or RTO, is how long the service can be unavailable before the business feels real damage. Both belong in the contract as the vendor's commitment, and both must match the organization's tolerance, not the vendor's default template. A vendor promising 99.9% uptime without an RTO commitment is promising less than it appears.

One relationship, one owner

In advisory work, the largest source of wasted third-party spend I have observed is not overpricing. It is diffused accountability. IT signs the contract. Legal reviews the terms. Security handles onboarding. Finance pays the invoice. Nobody owns the outcome. In that arrangement, the vendor is running the relationship.

Name one internal owner per third-party engagement. That person is accountable for the SLA being enforced, the business review happening, and the renewal decision being made on evidence rather than habit. This single change often does more for value realized than any amount of contract redlining.

A closing thought

Working with third parties is not a substitute for internal accountability. It is an extension of it. A well-managed provider relationship reduces cost, sharpens focus on the work only your team can do, and creates room for the organization to grow. A poorly managed one does the opposite. The difference is not the size of the vendor or the sophistication of the technology. It is the discipline of the organization engaging them.

Working with multiple IT vendors?

A short conversation can clarify where accountability, SLAs, or data governance would recover the most value.

Start the Conversation