How to vet a cybersecurity provider before you sign

To vet a cybersecurity provider, check 5 things before you sign: exactly what they will do, what access they need, how they prove their own security, how they report findings and incidents, and what happens to your data when the contract ends. Ask for each answer in writing and compare it with the contract.

This matters because a security provider is a supplier with unusual reach. Some only watch your company from outside, some install agents on every device, some hold administrator credentials. CISA's guidance for managed service provider customers puts it directly: outsourcing IT management "does not absolve an organization from risk management responsibilities."

The questions below work for monitoring services, penetration testers, managed detection and response, and consultants.

1. Define the scope in plain language

Ask the provider to describe, in one paragraph, what they will do and what they will not do. A good answer names the assets (domains, IP ranges, applications, devices), the activities (monitoring, testing, configuration, response) and the frequency.

Watch for:

• Vague descriptions such as "full protection" with no list of assets.
• Activities that change your systems, without a clear approval step.
• Deliverables that are only a score or a dashboard, with no explanation of individual findings.

2. Understand what access they need, and why

Access is the biggest difference between providers. Ask:

• Do you need credentials, VPN access, an agent or an API key? For what exactly?
• Is access read-only or can it change settings?
• Is every account named, protected by multi-factor authentication and logged?
• How quickly can we revoke it?

CISA recommends limiting provider accounts to the systems they manage and keeping them out of administrator groups. If a service can work with less access, prefer that design. Some services, such as external attack surface monitoring, need none at all (see what external attack surface monitoring is).

3. Insist on written authorization for any testing

Any activity that probes or tests your systems needs written authorization from you, with the exact targets and time window. In the US, accessing a computer without authorization falls under the Computer Fraud and Abuse Act, 18 U.S.C. 1030, and other countries have similar laws.

A professional provider will ask you for this document before starting. Be cautious with anyone who offers to test systems you do not own, such as a partner's website, or who starts scanning before paperwork is signed. It also tells you how they will treat other people's systems while working for you.

4. Ask for evidence, then check it

Statements in a sales deck are not evidence. Ask for:

• Independent audit reports or certifications where relevant, such as a SOC 2 report or ISO/IEC 27001 certification. Check the scope: which services and locations it covers.
• A sample report with findings, so you can judge whether your developers could act on it.
• Who reviews findings: a person, or only automated output.
• A list of their subcontractors and where your data is stored.

Then do your own quick check of the provider's external hygiene. A security company should pass the basics:

dig +short TXT _dmarc.provider-example.com
curl -sI https://provider-example.com | grep -i -E "strict-transport|content-security"

A missing DMARC record or missing security headers is not proof of poor work, but it is a fair question to ask. Our articles on SPF, DKIM and DMARC and HTTP security headers explain what to look for.

5. Agree on reporting, incidents and exit

Findings and incidents

Ask how a finding reaches you: by email, ticket, phone, a portal? Who receives it, and how fast? Good findings state what was seen, why it matters and the exact fix steps.

For incidents that affect you, put a notification obligation in the contract. If you are covered by NIS2 or sell to companies that are, the EU Implementing Regulation (EU) 2024/2690 (annex, point 5.1.4) lists contract terms such as notifying incidents without undue delay, the right to audit or receive audit reports, handling vulnerabilities, subcontracting rules and obligations at termination. It is a useful template even outside its scope; see NIS2 for suppliers.

Plan the exit before the start

Ask what happens when the contract ends:

• Which data they hold about you, and how it is returned and deleted.
• How their access, agents and accounts are removed, and how you can confirm it.
• Whether reports and history stay available to you.
• Notice periods and whether you can switch providers without losing your records.

A short checklist

• Scope in writing: assets, activities, frequency.
• Minimum access, named accounts, multi-factor authentication, easy revocation.
• Written authorization before any testing.
• Audit reports or certifications, with scope checked.
• Sample report with actionable fix steps, reviewed by a person.
• Incident notification terms in the contract.
• Subcontractors and data location listed.
• Exit plan: data return, deletion and access removal.

How Datahorses works

Datahorses watches your company from the outside every day, sees what an attacker can see, and sends each finding with exact fix steps, reviewed by a person. We do not enter your systems and need no access, so there is no account to revoke. You can read how we guard, the FAQ and about us, or look at the full example dashboard before you decide.