Walk into a sales meeting with a Melbourne MSP and ask “what’s in your security stack?” The answers tend to land in three buckets. Some will tell you, openly, what they run. Some will list category names (“EDR, MFA, application control”) without naming products. Some will give a vague “we use industry-leading enterprise tools”.
The third group is the one to worry about. And not because the products they use are bad — usually they’re fine. The reason it matters is that vagueness in the sales meeting predicts opacity in the contract, the SLA, and the offboarding process.
This post is about how to read a Melbourne MSP’s stack disclosure as a leading indicator of the relationship you’re about to sign up for.
Why MSPs get cagey about their stack
There are three honest reasons an MSP doesn’t volunteer their tooling on a first call. None of them are about you.
1. Competitive intelligence. If they tell every prospect what they use, it ends up on competitors’ comparison pages. Reasonable concern, but the answer should still be available under NDA, not “trust us”.
2. Tool churn. The serious MSPs change tooling every two to three years as the threat landscape shifts. They don’t want to commit to a specific product in a marketing document that’s outdated by month four.
3. Embarrassment. The dishonest reason: they’re using a budget RMM stack with a shaky security tier and they don’t want you to look it up.
The first two are fine — they’ll happily tell you under NDA or over coffee. The third is the one that matters.
The four questions that test stack maturity (without needing the product names)
You don’t actually need them to name the vendors. You need them to articulate the capabilities, in detail, with operational context.
1. “Walk me through what happens when an alert fires from your endpoint detection tool at 2am.” Bad answer: “we get a notification”. Good answer: “the alert hits our SOC, the on-call engineer triages within 15 minutes against our playbook, the affected device is isolated automatically if the alert is high-severity, then we contact you on the agreed escalation path”.
2. “What’s your patch cadence and what’s your reporting?” Bad: “we patch monthly”. Good: “we patch within 48 hours for critical vulnerabilities, 14 days for high, monthly for the rest, you get a report on the 1st of every month showing patch status by device”.
3. “How do you handle vendor end-of-life?” Bad: “we let you know”. Good: “we run an EOL register, you get six months’ warning before any platform we manage hits end-of-support, and we propose a replacement with comparable capability”.
4. “What’s the offboarding process if I leave?” Bad: “we’ll work that out at the time”. Good: “30 days’ notice, we hand over all documentation, all admin credentials are rotated to your new provider, and we run a 5-day handover engagement at no additional cost”.
What stack transparency tells you about contract risk
An MSP that volunteers operational detail is usually the one whose contract reads cleanly. An MSP that hand-waves the operational detail tends to write contracts with auto-renewal traps, vague exit clauses, and “we reserve the right to” rate increases.
It’s not a perfect correlation but it’s a strong one. We’ve never lost a comparison shootout where we offered the customer a side-by-side tooling and contract review in advance. The customers who don’t get one shouldn’t be deciding on price alone.
What we publish at TechAssist
Our 13 certified specialists work with a stack that’s been refined over more than a decade of running infrastructure for Melbourne SMEs across professional services, healthcare, manufacturing and education. We don’t list specific vendor names on our public site (we change them periodically and we don’t think a public marketing brochure is the right place), but we walk every prospect through the full stack under NDA before any contract is signed.
Our Melbourne managed IT service page outlines the capability list (24/7 helpdesk, EDR, MFA, application control, backup, M365 management). Our managed security page covers what’s included on the security side. The decision-maker’s MSP guide walks through what to ask and what to ignore.
What to do next
If you’re shortlisting Melbourne MSPs, ask each of them to walk through their stack under NDA before the contract conversation. Compare what you get back not on the product names but on how operationally specific each one is. The MSP whose answer reads like a runbook is the one you can build a real relationship with.
Ask us anything — we’ll send our stack disclosure under NDA before any sales conversation, and our contract before any handshake.
