Red flags your MSP is cutting corners on security

Your MSP holds the keys to your network, your data, and your regulatory posture. When they cut corners on security, the exposure lands on your firm—not theirs. The warning signs are rarely dramatic. They surface in missing log entries, unsigned change tickets, and contract language so vague it is unenforceable. Here is what to look for and what to demand.

Warning sign 1: Logs that don't tell the full story

Comprehensive logging is the foundation of incident response, forensic investigation, and regulatory compliance. If your MSP cannot produce a detailed activity log covering authentication events, configuration changes, privileged account access, and network anomalies for any given date range, that is a structural failure—not a billing issue to resolve at the next quarterly review.

Regulated firms under HIPAA, SOC 2, and state-level data protection rules frequently face audit requests that require log retrieval going back months. If those logs do not exist, your firm absorbs the compliance burden.

What to ask:

• What logging platform do you use, and what is the documented retention period?
• Can you produce a log of all privileged access to our environment from the last 90 days—today, without advance notice?
• Are logs stored in an immutable, tamper-evident format separate from the systems they monitor?

Warning sign 2: No formal change management process

Every configuration change to your environment—firewall rules, user permissions, software installations, network segments—should be documented in a change ticket before it happens. This is not bureaucracy. It is the mechanism that separates authorized changes from unauthorized ones and makes post-incident forensics possible.

MSPs that operate informally, where a technician makes a change and notes it after the fact—or not at all—cannot tell you with confidence whether a change that preceded an outage or breach was planned or was an intrusion. That ambiguity is dangerous in a regulatory inquiry.

What to ask:

• Walk me through your change management workflow. Is there a ticketing system, an approval chain, and a documented rollback procedure?
• How do you distinguish an emergency change from an unauthorized change?
• Can I access change records for my environment on demand, without submitting a request through your helpdesk?

Warning sign 3: Inadequate MFA enforcement

Multi-factor authentication is no longer optional for any business handling regulated data. The specific implementation matters, however. SMS-based one-time codes are susceptible to SIM-swapping attacks. Security questions are not MFA. An MSP that considers either adequate is operating below current standards.

More critically, MFA enforcement must cover the MSP's own remote access tools—the RMM (remote monitoring and management) platform and the PSA (professional services automation) system. If a technician can reach your environment through a vendor portal secured only by a username and password, every other control downstream is weakened.

What to ask:

• What MFA method do you require for technician access to our environment?
• Is MFA enforced on your RMM platform? Can you show written documentation of that policy?
• Do you require phishing-resistant MFA—hardware keys or passkeys—for any privileged access role?

Warning sign 4: Contract language that commits to nothing

Vague contractual language is how MSPs limit liability while creating the impression of accountability. Watch for these specific patterns:

• "Industry-standard security practices." This phrase is unenforceable. Which standard? NIST CSF? CIS Controls? ISO 27001? The contract should name the framework explicitly.
• "Best efforts." In a security context, best efforts is not a measurable commitment. You cannot audit a best effort, and neither can a regulator.
• No incident notification timelines. If the contract does not specify when and how you will be notified of a suspected breach, your MSP can take days to tell you—days during which your legal and regulatory clock is already running.
• Indemnification clauses that run one way. Some MSP agreements indemnify the provider against your claims while accepting no reciprocal obligation. That is a contract written for the provider's benefit.

How to conduct a basic security audit of your MSP

You do not need a penetration tester to start this process. A structured set of documentation requests will surface most gaps.

1. Request their most recent third-party security assessment. A credible MSP undergoes periodic external audits—SOC 2 Type II reports, penetration test summaries, or vulnerability scan results. If they cannot produce one, that absence is itself a finding.
2. Ask for your environment's configuration baseline. You should receive a documented record of how your systems are configured, which software is authorized, and which ports are open. If this document does not exist, configuration drift is likely unmanaged.
3. Review incident response procedures in writing. Ask for the runbook. It should specify roles, communication chains, containment steps, and escalation paths. A verbal description is not a procedure.
4. Test log retrieval without warning. Request a log export for a specific date range without giving advance notice. Note how long the response takes and whether the output is complete.

Contractual language that protects your firm

When renewing or negotiating an MSP agreement, these provisions should appear in plain, measurable terms:

• Named security frameworks. The agreement should specify which framework governs the provider's security obligations—not a generic reference to industry norms.
• Breach notification timelines. Define the maximum hours from detection to client notification. Not "promptly"—a number.
• Audit rights. You should have the explicit contractual right to request documentation, review logs, and commission a third-party assessment of the provider's practices affecting your environment.
• Data handling on termination. The contract should specify what happens to your data and credentials when the relationship ends, including timelines for return and verified destruction.
• Subcontractor disclosure. If your MSP uses subcontractors or offshore resources with access to your environment, the contract should require disclosure and extend security obligations to those parties.

An MSP that resists adding these provisions should be asked why. The answer will tell you more than the contract itself.

Related reading

• What "Fully Managed IT" Should Actually Include for a 10-Person Firm
• What your clients' contracts already require you to have
• Cyber Insurance Will Not Pay If You Skipped the Basics: 2026 Small-Firm Edition