Skip to main content
Managed IT

12 Questions to Ask an IT Managed Service Provider in Singapore (2026)

23 June 2026·10 min read
Four colleagues discussing IT vendor proposals around a meeting table with laptops, flowchart printouts, and a Singapore skyline view
TL;DR

Most Singapore businesses pick an MSP based on price and a reference from someone they know. These 12 questions cut through the sales pitch and tell you what you actually need to know before signing a contract.

Most Singapore businesses choose a managed IT services provider based on two things: price and a word-of-mouth referral. The price comparison is done on the monthly retainer. The referral is from someone who knows the sales director. Neither of these tells you how the provider performs when your email server goes down at 9 AM on a Monday, or how they handle a PDPA data incident, or what happens to your systems documentation when you decide to switch providers.

These 12 questions will. Ask all of them before you sign.


1. What are your response time guarantees by priority level — and can I see last quarter's actual delivery data?

Every MSP will tell you they have SLAs. The question is whether those SLAs are contractual commitments with defined consequences, or aspirational targets that appear in the proposal and nowhere else.

What to ask for specifically:

  • P1 (business-stopping): target response time and resolution time
  • P2 (significant impact, workaround possible): targets
  • P3 (minor, degraded service): targets
  • Actual MTTR (Mean Time to Resolution) data from the last 90 days

Good answer: A specific table of P1/P2/P3 targets, combined with a genuine willingness to share recent performance data. A confident provider has nothing to hide.

Red flag: "We aim to respond within a few hours for most issues" or "Our team is very responsive." Vagueness here is a contractual risk. If it is not in writing with defined penalties, it is not a commitment.

Why it matters in Singapore: Singapore businesses operate in a high-density, always-on environment. A manufacturing or logistics company may struggle to absorb 4 hours of downtime on a warehouse management system. Financial services firms also need clear IT incident records for governance, audit, and regulatory review.


2. How do you handle after-hours and public holiday coverage?

Singapore has 11 public holidays. Your MSP's coverage model on a Deepavali Monday or Chinese New Year morning matters.

What to ask:

  • Is there a 24/7 NOC (network operations centre) watching your systems, or does monitoring pause after business hours?
  • Who picks up a P1 call at 2 AM — an on-call engineer or an answering service?
  • Is after-hours support included or charged at a premium rate?

Good answer: A staffed NOC with 24/7 monitoring, documented escalation procedures, and clear inclusion of public holidays in the base SLA. The engineer who responds after hours should be the same calibre as the one who responds during the day.

Red flag: "We have an on-call number" with no further detail. This usually means one engineer's personal mobile, and they will not be happy to hear from you at 2 AM.


3. What happens to my IT if one of your engineers leaves?

Staff turnover in Singapore's IT sector is high. Engineers with current certifications are in demand. What happens to your business continuity when the engineer who knows your environment intimately resigns?

What to ask:

  • How is client environment documentation maintained, and where does it live?
  • What is your average engineer tenure?
  • If my dedicated account engineer leaves, what does the transition look like?

Good answer: A managed IT provider worth engaging maintains a living documentation system — network diagrams, asset registers, runbooks, password vaults — that is not stored in an individual's head or personal laptop. The system, not the person, should hold the knowledge of your environment.

Red flag: No clear documentation policy, or documentation that sits with a named individual rather than in a shared, version-controlled system.


4. Walk me through your PDPA compliance position — who is your DPO?

Under Singapore's Personal Data Protection Act, when you engage an MSP to process personal data on your behalf, they are acting as a data intermediary. You remain the data controller. If they mishandle your customer or employee data, you carry the regulatory exposure.

What to ask:

  • Who is your designated Data Protection Officer (DPO)?
  • How do you handle data stored or processed in your systems or tools?
  • Have you had any PDPA incidents or PDPC investigations in the last three years?
  • What are your staff background-check procedures?

Good answer: A named DPO (required for organisations with data processing operations), a documented data protection policy, clear answers about where client data is stored and under what access controls.

Red flag: "We take data security very seriously" without specifics. This question requires a procedural answer, not a values statement. Any provider without a named DPO should be treated with caution.


5. Do you have experience with MAS TRM requirements? (For financial institutions)

If your business is licensed by the Monetary Authority of Singapore — a bank, insurer, payment institution, capital market services licensee — your MSP's IT practices must align with MAS Technology Risk Management Guidelines.

MAS TRM expectations commonly cover areas such as:

  • Annual penetration testing of critical systems
  • IT incident notification within specified timeframes
  • Documented disaster recovery with tested RTO/RPO
  • Privileged access management and audit trails

What to ask:

  • Can you provide examples of MAS-regulated clients you currently support?
  • How do your monitoring and logging practices align with MAS TRM audit requirements?
  • Who in your team holds relevant compliance certifications (CISM, CISSP, ISO 27001 Lead Auditor)?

Good answer: Specific familiarity with MAS TRM language, documented examples of supporting regulated clients, named certifications in the team.

Red flag: A blank look or a generic "yes we handle compliance" without any specificity. MAS TRM has precise technical requirements. An MSP that cannot speak to them in detail has not been supporting regulated clients.


6. What does your onboarding look like in the first 30 days?

The first 30 days of an MSP engagement are the highest-risk period. Your previous systems documentation may be poor. The MSP does not yet know your environment. Issues will surface that were invisible before.

What to ask:

  • What is the day-0 to day-30 onboarding plan?
  • Who leads the onboarding — a dedicated project manager or the same engineers who handle support?
  • When will the first patch baseline and vulnerability scan run?
  • Is a disaster recovery test included in the first 30–90 days?

Good answer: A structured written plan with named milestones: discovery and asset inventory, patch baseline, security baseline, DR test, and a 30-day review call. Good onboarding is not improvised.

Red flag: "We will get you set up over the first few weeks." No written plan, no milestones, no DR test. If the onboarding has no structure, the ongoing management likely will not either.


7. What is NOT included in the monthly fee?

Every managed IT contract has a scope boundary. The question is whether that boundary is clearly defined before you sign, or discovered during your first invoice dispute.

What to ask:

  • Is on-site support included or charged additionally?
  • Are project work (office moves, new server deployments, migrations) in scope?
  • Is after-hours emergency support included or an add-on?
  • Are software licences included or billed separately?
  • What triggers an out-of-scope charge?

Good answer: A clear written scope document with explicit exclusions. A credible MSP will walk you through what is outside the retainer without prompting because they want to avoid invoice disputes as much as you do.

Red flag: Vague language about "reasonable IT support" without a defined scope. You will find out what is excluded when you receive a supplementary invoice.


8. What tools do you use for remote monitoring, and can I see my environment's dashboard?

Your MSP uses a set of tools to manage your environment. You should know what those tools are, and ideally have visibility into what they are seeing.

What to ask:

  • What is your RMM (remote monitoring and management) platform?
  • What EDR (endpoint detection and response) tool is deployed on endpoints?
  • Do you use a PSA (professional services automation) tool for ticketing?
  • Can I access a client portal showing open tickets and system health?

Good answer: Named tools (e.g., ConnectWise, Kaseya, SentinelOne, CrowdStrike, Datto RMM) and a genuine client portal with real-time visibility. You should be able to see your own ticket status and system health without having to call the helpdesk.

Red flag: "We use industry-standard tools" with no specifics. An MSP that cannot name their toolstack either does not use best-in-class platforms or is hiding something.


9. What is your own internal security posture?

Your MSP has privileged access to your entire environment. They can see your files, your credentials, your communications infrastructure. Their internal security is your security.

What to ask:

  • Do all your staff use MFA on all internal and client-facing systems?
  • How are client credentials and passwords stored? (The answer should be a privileged access management vault, not a shared spreadsheet.)
  • Have you undergone any third-party security audit or penetration test? When was the last one?
  • What is your background screening process for engineers who access client environments?

Good answer: MFA enforced organisation-wide, a named PAM tool (CyberArk, BeyondTrust, or equivalent), recent penetration testing, and background checks as a hiring requirement.

Red flag: Any hesitation on the MFA question. If your MSP's staff do not use MFA everywhere, your accounts are one credential theft away from a breach that originates from your trusted vendor.


10. Can you provide three client references from businesses similar to mine in size and industry?

References are a basic requirement. Three matters more than one. Similar size and industry matters because a reference from a 500-person bank does not tell you how the provider handles a 40-person logistics firm.

What to ask:

  • Three references with names, company names, and direct contact numbers
  • Specifically request clients who have been with the provider for at least 2 years
  • Ask if you can see a case study or speak to the client about a specific incident and how it was handled

Good answer: References provided without hesitation, including at least one who has experienced and resolved a serious IT incident with the provider.

Red flag: References available only as testimonial quotes on the website. Testimonials are curated. Direct conversations are not.


11. Have you ever experienced a security incident affecting client data? How was it handled?

This is the question most people do not ask. It is one of the most important.

A provider that has experienced an incident and handled it well — disclosed it promptly, contained it quickly, documented lessons learned — is more trustworthy than one that claims a spotless record and cannot speak to incident response from experience.

What to ask:

  • Have you had any security incidents affecting client environments in the last three years?
  • If yes: What happened, how was it contained, and what changed afterwards?
  • What is your incident response plan for a client data breach, and at what threshold do you notify the client?
  • Under PDPA, a notifiable data breach must be reported to the PDPC as soon as practicable, and no later than 3 calendar days after the organisation assesses it to be notifiable. How does your incident response timeline align with this?

Good answer: Honest disclosure if incidents have occurred, a clear incident response plan, PDPA notification timeline that meets the 3-day requirement.

Red flag: "We have never had a security incident." Either they have not been doing this long enough or they have not been looking.


12. What does your offboarding process look like?

This question signals that you are a serious buyer. It also tells you a great deal about how the provider thinks about the relationship.

What to ask:

  • What is the notice period required to terminate the contract?
  • How long does it take to transfer documentation, credentials, and system access to a successor provider?
  • Do you assist with handover to a new MSP, or is offboarding the client's responsibility?
  • Will all credentials, admin access, and documentation be transferred within a defined timeframe?

Good answer: A clear, short notice period (30–90 days is standard), a structured handover process, and genuine commitment to a clean transition including full credential transfer and environment documentation.

Red flag: Long lock-in periods with penalties, vague handover commitments, or any indication that documentation "lives with the team" and would take months to compile. This is either a sign that documentation is not maintained properly, or that the provider uses lock-in as a retention strategy.


What These Questions Are Really Testing

The answers matter less than the quality of the conversation they produce. An MSP that has clear, specific, documented answers to all 12 questions has built operational maturity. They have been through the pain of incidents, transitions, and scope disputes, and they have built systems to manage them.

An MSP that responds with marketing language, deflects specific questions, or cannot name their tools is either early-stage or has something to hide.

Singapore's IT services market has a wide quality range. At the top are providers with documented processes, trained teams, proper compliance posture, and genuine 24/7 coverage. At the bottom are one-to-three person operations running on personal relationships and best effort. Price is not a reliable signal for which category you are dealing with. These questions are.


If you want to benchmark a proposal you have received, or want to understand what a properly structured managed IT engagement looks like, talk to our team. We will walk through the questions on this list with your actual environment in mind.


Frequently Asked Questions

How do I evaluate an MSP's technical capability during a sales pitch?

Ask for specifics rather than accepting general assurances — a specific table of P1/P2/P3 response time targets with actual MTTR data from the last 90 days, named tools for RMM, EDR, and PSA ticketing, and named certifications held by the team (CISM, CISSP, ISO 27001 Lead Auditor). An MSP with operational maturity has clear, documented answers to direct questions; one that responds with marketing language or deflects specifics is either early-stage or has something to hide.

What SLA response times should I expect from a Singapore MSP?

Expect a defined table of response and resolution targets by priority level — P1 (business-stopping), P2 (significant impact with a workaround), and P3 (minor, degraded service) — as contractual commitments with consequences, not aspirational language like "we aim to respond within a few hours." You should also be able to request the provider's actual delivery data from the last quarter to verify they meet these targets in practice, and confirm whether public holiday and after-hours coverage is included in the base SLA or charged as a premium.

What's typically included in a managed IT contract versus billed separately?

Every managed IT contract has a scope boundary that should be defined in writing before you sign, not discovered on your first invoice. Ask specifically whether on-site support, project work (office moves, new server deployments, migrations), after-hours emergency support, and software licences are included or billed as add-ons. A credible MSP will walk you through the exclusions without prompting, because unclear scope leads to invoice disputes that cost them client trust.

How long does onboarding to a new MSP typically take?

A structured onboarding runs through the first 30 days and should follow named milestones: discovery and asset inventory, a patch baseline, a security baseline, and a 30-day review call, with a disaster recovery test typically included within the first 30–90 days. This period is the highest-risk window in any MSP engagement because the provider does not yet know your environment, so ask specifically whether a dedicated project manager leads onboarding and request the written plan before signing.

How hard is it to switch MSPs if the current one underperforms?

This depends heavily on the notice period and how documentation is maintained. A reasonable notice period is 30–90 days, and a credible provider commits to transferring all credentials, admin access, and documentation to a successor within a defined timeframe. The risk sign to watch for is documentation that "lives with the team" rather than in a shared, version-controlled system — this either means it isn't maintained properly or the provider is using lock-in as a retention strategy, both of which make switching slow and costly.


Ask Aggasys These Questions Directly

Aggasys welcomes being asked all 12 of these questions directly — book a discovery call and we'll walk through our answers to each one, with references you can verify.

aggasys.com/contact or call (+65) 6250 0045

Explore this service
Managed IT Services →
Related guides
IT Basics
What Is a Managed Service Provider (MSP)? A Guide for Singapore Business Owners
9 min read
Managed IT
Managed IT Services vs In-House IT Singapore: The Real Cost Breakdown (2026)
12 min read
← Back to all resources