Most technology decisions feel high-stakes until you're actually locked into a bad one. Then they feel catastrophic. 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? Every provider says they do all three. The questions below help you tell who actually does.
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. "We're very responsive" is not 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. A fast response that goes nowhere is just fast failure. 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. That works until it doesn't.
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. A provider who treats security as a checklist item is a liability. You want one who treats it as an ongoing discipline.
4. How do you handle backups, and when did you last test a restore?
Backups that haven't been tested are not backups. They're hope. 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. Either answer should concern you.
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 via policy, not a recommendation that employees can opt out of. 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? A trustworthy firm answers without hesitation.
8. Who owns the code when the engagement ends?
This should be non-negotiable: you own the code. Your work product, your intellectual property, full stop. 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 a discipline, not an afterthought. 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?
A product built by engineers without design input often works but doesn't convert. A brand built without technical input often looks great but can't scale. A good answer describes a process where these disciplines interact early and regularly, not where design hands off a Figma file and developers build it verbatim with no questions asked.
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. If the answer is abstract, the silos are real.
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 the landscape, not one who defaults to what they already know.
Transparency and Fit
The relationship questions are often the ones people skip because they feel soft. They're not. 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 tells you whether a provider is managing your environment or just billing for it. 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, not just 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's a provider who is managing the relationship optics rather than your actual IT environment.
13. What happens to pricing over time, and how much notice do you give for changes?
Year-one pricing is often not year-three pricing, and 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.
Exit strategy clarity is a proxy for how the whole relationship will go. If they're transparent and practical about this, they're likely transparent and practical about everything.
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, not a cherry-picked enterprise client if you're a 30-person firm. 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. Our helpdesk operates during business hours with after-hours escalation paths for critical incidents. We don't promise what we can't deliver, and we track our SLA adherence as an internal performance metric.
On security: MFA is a requirement, not a recommendation, 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: our development team is in-house. You own the code, full stop, and we deliver structured documentation at project close as a standard deliverable, not an add-on. 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: we believe design and technology decisions should inform each other from the start of a project, not at handoff. Our teams work together on the same projects, which means fewer mismatches between what's designed and what gets built.
On transparency: we do quarterly 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.
