Choosing a technology partner is a high-stakes decision, and a bad choice is hard to undo. Whether you're evaluating a managed IT provider, a software development team, or an agency to run your digital presence, the wrong partner costs you more than money. It costs you time you can't recover, projects you have to redo, and trust you have to rebuild with your own team and customers.
The difference between a vendor and a real partner comes down to three things: are they proactive about your problems or reactive to your tickets, do they communicate with you honestly or manage you, and are they invested in outcomes or just deliverables? The questions below help you tell which providers actually do all three.
Use this as a working checklist before your next evaluation. You don't have to ask every question in a single meeting, but you should have answers to all of them before you sign anything.
Service and Support
Support is where the relationship either holds or falls apart under pressure. Most organizations discover their provider's real support posture the first time something breaks badly at the wrong hour.
1. What are your response time commitments, and what triggers them?
A good answer is specific: response time targets by severity level, defined in a service level agreement (SLA), with consequences if those targets aren't met. Look for tiered definitions. A downed server at 2am should get a different response than a slow printer on a Tuesday afternoon, and a good provider has thought through both.
The red flag is vagueness, such as "we're very responsive" in place of an SLA. If they can't tell you the difference in response time between a P1 and a P3 incident, their support is informal at best and chaotic at worst. Ask to see a sample SLA before you sign.
2. What's your escalation process when the first responder can't solve the problem?
Escalation matters more than initial response speed. You want to understand who escalates, to what level, and when. Does escalation require you to call someone or does it happen automatically? Is there a senior engineer or a dedicated account manager who gets looped in when a ticket has been open too long?
A provider with no clear escalation path is relying on the first person who picks up the phone to solve everything.
3. Do you provide on-site support, and under what conditions?
Remote support handles the majority of issues efficiently, but some situations genuinely require a person in the room: a server that won't boot, a network outage with physical components involved, or an employee who needs hands-on help that doesn't translate over a screen share. Know upfront whether on-site visits are included in your contract, billed separately, or not available at all. If your provider is headquartered three states away, factor that in.
Security and Compliance
Security questions reveal how a provider thinks about risk. You want a provider who treats security as an ongoing discipline.
4. How do you handle backups, and when did you last test a restore?
You can't rely on backups that haven't been tested. A solid answer covers the 3-2-1 rule (three copies, two media types, one offsite), specifies how often backups run, how long they're retained, and whether they're immutable or air-gapped so ransomware can't reach them. Then the important part: when was the last time they performed a full restore test, and what did they find?
If they can't tell you the last restore test date, they either don't test or don't track it.
5. Do you require MFA across your clients' environments, and how do you enforce it?
MFA is the most well-established, highest-return security control available. A provider who treats it as optional is behind the times. The right answer is that MFA is a standard requirement enforced by policy. Ask how they handle exceptions, because there are always people who push back, and how they manage MFA for service accounts and privileged access.
Watch out for providers who enable MFA but leave legacy authentication protocols open. That's a gap that bypasses MFA entirely and one that sophisticated attackers know to look for.
6. What security frameworks do you follow, and can you map your services to them?
NIST CSF, CIS Controls, SOC 2, HIPAA, and ISO 27001 are the most common reference points. A provider doesn't have to be certified in all of them, but they should be familiar with at least one and able to explain how their service delivery maps to its controls. If you operate in a regulated industry, this question is mandatory. If they can't answer it, that's a meaningful gap.
Engineering and Development
Software questions separate firms with real engineering capability from those who resell offshore capacity under their own letterhead. Both models can work, but you deserve to know which one you're buying.
7. Is your development team in-house, or do you subcontract?
There's no universally right answer here, but there is a right answer for you depending on your priorities. In-house teams typically offer tighter communication, more consistent quality control, and clearer accountability. Subcontracted or hybrid teams can offer broader skill coverage and faster scaling. What you don't want is a firm that tells you everything is in-house and then quietly hands your project to a vendor you've never met.
Ask directly: who will be writing the code? Where are they located? Are they employees or contractors?
8. Who owns the code when the engagement ends?
You should own the code: your work product and your intellectual property. Some vendors retain code ownership or build on proprietary platforms that lock you into their ecosystem indefinitely. Read the contract carefully on this point. If ownership isn't explicitly assigned to you, it isn't yours.
Also ask about documentation and knowledge transfer. Owning the code is only useful if someone can actually maintain it after the engagement ends. A provider who resists documentation is either protecting their lock-in or cutting corners on process.
9. How do you handle documentation and knowledge transfer at the end of a project?
Good documentation is part of the work. Ask what they deliver at the end of a project: architecture diagrams, API docs, deployment runbooks, credential inventories, codebase comments. Then ask what format and where it lives. "We'll give you a folder of docs" is very different from a maintained wiki with version history that your internal team can actually use.
Red flag: any resistance to documentation requests or framing documentation as out-of-scope work. That tells you they haven't thought carefully about your long-term success, only the current engagement.
Creative and Strategy
Technology decisions don't exist in a vacuum. The best providers understand that the software, the brand, and the user experience have to work together, and they know how to connect those disciplines without requiring you to manage three different agencies.
10. How do you connect branding, UX, and technology decisions?
Products built without design input often work but don't convert, and brands built without technical input often can't scale. A good answer describes a process where these disciplines work together early and often.
Ask for an example of a project where a design or brand decision directly influenced a technology choice, or vice versa. If they can walk you through a real scenario, they've actually done it.
11. How do you stay current with platform and technology recommendations?
The tools change. Frameworks evolve. A provider recommending the same stack they were selling five years ago without being able to explain why it still fits is either lazy or protecting their own expertise. Ask how they evaluate new platforms and how recently they've changed a recommendation based on something better coming along. You want a provider who is curious and honest about new options.
Transparency and Fit
People often skip the relationship questions because they feel soft, but they predict whether a partnership works at month 18 the same way it worked at month 1.
12. What does your reporting look like, and how often will we review it together?
Reporting shows you how a provider is managing your environment. A strong answer describes regular business reviews (at least quarterly), specific metrics they track for your account, and how they connect those metrics to your business outcomes as well as uptime percentages and ticket close rates.
The red flag here is reporting that's designed to look impressive without being meaningful. If you're getting a dashboard full of green checkmarks every month but no commentary on what changed, what's coming, or what decisions you need to make, that provider is managing appearances.
13. What happens to pricing over time, and how much notice do you give for changes?
Pricing often changes between year one and year three. That's fine as long as you know the rules. Ask specifically about escalation clauses, what triggers a price change, and how much advance notice you'll receive. A fair provider has transparent terms and doesn't bury annual increases in addenda you have to catch on the invoice.
Also ask whether pricing scales predictably as your team grows or shrinks. Per-user or per-seat models are generally easier to forecast than flat-fee arrangements with unclear limits.
14. What does offboarding look like if we decide to leave?
No one likes asking this in a sales conversation, but ask it anyway. A provider who is confident in their work shouldn't have any trouble describing a clean offboarding process: credential handoff, documentation transfer, knowledge transfer calls, a reasonable transition period. A provider who responds to this question with hedges, fees, or vague timelines is already planning to make leaving difficult.
How clearly a provider explains offboarding tells you a lot about how the rest of the relationship will go.
15. Can you connect us with a current client in a similar industry or at a similar size?
References are standard practice and any credible provider should have several they can connect you to quickly. The most useful references are clients who are similar to you in industry, size or complexity. When you do the call, ask that client what surprised them about working with the provider, what they would change, and whether they've renewed and why.
If a provider can't produce a reference within a few days, that's a meaningful signal about either their tenure in the market or their client retention.
How Canyon Answers These Questions
We think every one of these questions is fair, and we're comfortable with all of them. Here's how we approach each area for our clients.
On support: our managed IT clients have documented SLAs with tiered response commitments. Response times and coverage are set out in each client's Managed Services Agreement. We don't promise what we can't deliver, and we track our SLA adherence as an internal performance metric.
On security: MFA is required in every managed environment we operate. We follow CIS Controls as our baseline security framework, perform regular configuration reviews against that benchmark, and include backup testing as a standard part of our managed service. For organizations that need a deeper assessment or incident response support, our cybersecurity practice handles both.
On engineering: we staff each project from our own bench and a network of specialists we know, and we tell you who is writing your code before work starts. You own the code, and we deliver structured documentation at project close as standard. We're built on a modern stack and willing to explain our choices and consider alternatives when something better fits your situation.
On creative and strategy: design and technology decisions inform each other from the start of a project. Designers and engineers work on the same projects, which means fewer mismatches between what's designed and what gets built.
On transparency: we hold regular business reviews with managed clients, provide honest reporting on what's working and what needs attention, and our contracts are written to be read. We'll walk you through every clause if you want.
If you're in the middle of evaluating technology partners and want to have this conversation directly, reach out here. We're happy to answer any of these questions on the record.
