Most provider evaluations start with features: which firewalls are supported, what the portal shows, and how quickly a critical ticket will be acknowledged. Those questions matter, but they miss the larger risk. A managed provider commonly receives remote access, service accounts, log data, and enough operational authority to make production changes. That access can improve security when it is controlled well. It can also widen the blast radius of a stolen credential or a compromised provider.

CISA has warned about attackers using managed service providers as a route into customer networks. Its guidance is direct: restrict provider accounts to the systems they manage, use strong authentication, centralize logs, and define security responsibilities in the contract. That is a better starting point than a tour of the provider’s dashboard.

Start with access, not the dashboard

Ask for an access diagram. It should show how provider staff connect, where authentication happens, which customer systems they can reach, and where their actions are logged. “Our engineers use the portal” is not enough. You need to know what sits behind the portal.

The practical baseline is least privilege: separate named accounts, multifactor authentication, no shared administrator credentials, and access limited to the devices and functions covered by the service. Emergency elevation should be time-limited and logged. If a subcontractor may receive access, the same rules should apply to that subcontractor and the contract should say so.

Logging belongs in the design, not in a footnote. Keep an independent record of provider authentication and administrative changes in a system the provider cannot silently alter. CISA recommends central logging and regular review; its joint guidance for MSPs and customers also calls for clear incident-notification terms and an understanding of the provider’s access to customer data.

Write down the operating boundary

“Managed firewall” can describe several different services. One provider may monitor health and open recommendations. Another may approve and push policy changes. Neither model is automatically wrong, but ambiguity is.

For each recurring task, name who is responsible, who approves it, and who must be informed. Cover at least:

  • policy changes and emergency blocks;
  • software upgrades and vulnerability response;
  • certificate renewal;
  • log review and alert investigation;
  • backup, restore, and disaster recovery;
  • incident containment, evidence preservation, and notification; and
  • changes made by vendors or other third parties.

NIST’s Cybersecurity Framework 2.0 supply-chain guidance recommends documenting roles for suppliers and customers, including those roles in agreements, and defining how information will be shared. A simple responsibility matrix is useful here. Its value is not the format; it is forcing both sides to resolve gaps before an urgent change exposes them.

Measure the work that matters

Time to acknowledge a ticket is easy to measure. It does not show whether the provider restored service, removed the cause, or stopped the same alert from returning next week.

Pair response-time targets with operational measures. Useful examples include time to containment, time to restore, repeat incidents caused by the same condition, overdue high-risk changes, failed backups, and policy changes without an identified owner. Define how each number is calculated. Otherwise two teams can report the same label while measuring different events.

Ask to see a redacted monthly report and a redacted incident report. The monthly report should show exceptions and aging work, not only green percentages. The incident report should include a timeline, decisions, evidence retained, corrective actions, and named owners. If the provider cannot show how it documents a real event, a sample service-level chart tells you very little.

Test the exit before signing

Offboarding is part of security architecture. The contract should say what data you can export, in what format, how quickly access will be removed, how secrets will be rotated, and when the provider will delete retained customer data. It should also cover configurations, change history, asset inventories, runbooks, open incidents, and logs.

Do not accept “industry-standard format” without an example. Ask for a sample export and confirm that another team could use it without the provider’s private tooling. If the service includes provider-owned collectors or agents, document how they will be removed and what monitoring gap that removal creates.

Exit planning is not an accusation. Providers change, customers reorganize, and products are retired. A clean handoff protects both parties.

A short procurement checklist

  • Access: Are accounts named, least-privileged, MFA-protected, time-bounded when elevated, and logged outside the provider’s control?
  • People: Who can make a production change, and who takes over if the assigned engineer is unavailable?
  • Subcontractors: Which organizations may touch systems or data, and how are they approved?
  • Incidents: Who declares an incident, who can contain it, and how quickly must the customer be notified?
  • Evidence: Which logs are retained, for how long, and who can retrieve them during an investigation?
  • Reporting: Does reporting show remediation and recurrence, or only response and closure times?
  • Recovery: When were restore and failover procedures last exercised?
  • Exit: What will be returned, what will be deleted, and how will every provider credential be revoked?

No checklist proves that a provider will perform well. It does make the operating model visible. That is the point: security work is easier to govern when access, authority, evidence, and accountability are explicit.

Sources

Source note: CISA and NIST describe risk-management practices, not a certification of any provider. Contract terms and regulatory duties vary by organization and jurisdiction.