IT Provider Not Responding? What to Do When Your MSP Lets You Down

When your IT provider stops answering, the problem is bigger than the unanswered ticket. You pay for managed IT precisely so that someone is watching your systems, and silence means nobody is. What you do next depends on whether you're facing slow support, a stalled relationship, or a security concern that nobody is investigating, and each deserves a different response.

Work out which kind of silence this is

Start by triaging honestly. A delayed response on a printer issue or a new-equipment request is an irritation. A delayed response while staff can't access email or a shared system is a business interruption. And no response at all to something that looks like a security problem — unusual account activity, a suspicious email that someone clicked, files behaving strangely — is an emergency, full stop. The first two justify escalation; the third justifies acting immediately through every channel you have, including picking up the phone and asking for a principal of the firm.

Document before you escalate

Before you write the strongly worded email, build the record. List every open ticket with its number, the date you raised it, the responses received (or not), and the business impact while it sat unresolved. Keep this log contemporaneously from now on. Documentation converts "you've been slow lately" into specific, dated evidence, which changes the tone of the conversation and becomes essential if the relationship ends in a contract dispute or an exit negotiation.

Escalate formally, in writing

Dig out your service agreement and find the response and resolution commitments it contains. Write to your account manager, copied to a director or owner of the provider, referencing those commitments against your documented experience, and ask for two things: resolution of the outstanding items, and a written remediation plan with dates for how service will improve. If your agreement contains no response commitments at all, that's a finding in itself, and worth fixing in whatever agreement comes next. A reasonable provider treats a letter like this as a wake-up call. A provider who doesn't respond to formal escalation has answered your real question.

Treat a suspected security incident as its own emergency

Never let a possible breach sit in a general support queue. Phone the provider and say the words "suspected security incident" — those words should trigger a different process. If they don't engage promptly, get an independent incident responder involved rather than waiting, and take the containment steps you can take yourself: reset passwords on affected accounts, enable or verify multi-factor authentication, and isolate any machine behaving suspiciously. Be aware that Australian privacy law imposes notification obligations for certain data breaches, so check the OAIC's current guidance rather than assuming silence is an option for you, whatever your provider is doing.

Secure your position before you decide to leave

Whether or not you ultimately switch, close the dependency gap now, while the relationship still nominally functions. Confirm that your business holds admin credentials for your Microsoft 365 tenancy, your domain registrar, your firewall and your backup platform, and that they aren't known only to the provider. Verify that backups actually exist and that a restore has been tested. Ask for an up-to-date inventory of everything the provider manages, and confirm which software licences are owned by you versus resold through them. Businesses that skip this step discover, mid-divorce, that their supplier holds the keys to everything.

Switch without leaving a gap

If the pattern doesn't improve after formal escalation, persistent failure against agreed service levels is legitimate grounds to move on. Do it in the right order: shortlist and engage the replacement first, because a competent incoming MSP will manage the transition, request the handover documentation, and take over monitoring before the old arrangement ends. Check your existing contract for notice periods and offboarding obligations, and insist on a proper handover of documentation, credentials and configuration records as a condition of final payment where the contract allows.

The deeper lesson is that IT support should never run on chasing. Response commitments in writing, credentials in your own hands, and a provider who reports to you proactively are what make the function dependable — the same principle that underpins a well-run operations function generally. A provider who makes you feel like their only client when something breaks is the standard to hold out for.