Your company pays a managed service provider to run IT and security. Leadership wants to know whether the MSP would actually notice an attacker, so someone suggests commissioning a penetration test without telling them. Others worry that it will damage the relationship, breach the contract, or trigger an incident response that costs everyone a weekend.
Unannounced tests are a legitimate tool, but only when done properly. A covert test of your MSP’s detection and response is reasonable if you, as the system owner, authorise it in writing, check your MSP contract for notification and testing clauses, define strict rules of engagement, and name a trusted contact who can stop the MSP from escalating to law enforcement or wiping systems. If you only want to find vulnerabilities, an announced test is cheaper and more thorough. If you want to know whether anyone would notice, a covert test is the only honest measurement.
Two different questions, two different tests
NIST’s technical guide to security testing (SP 800-115) distinguishes between the two. Overt testing happens with the knowledge and consent of IT staff, which lets them guide the testers, limit impact and learn from the exercise. Covert testing is performed without the knowledge of IT staff but with the full knowledge and permission of upper management, and examines how much damage an adversary could do and how the organisation responds.
| You want to know | Better choice |
|---|---|
| Where are our vulnerabilities? | Announced penetration test with MSP cooperation |
| Would our MSP detect and respond to a real attack? | Covert test or red team exercise with a trusted agent |
| Does our MSP’s reporting match reality? | Covert test followed by comparison with the MSP’s alerts and tickets |
What must be in place before a covert test
- Written authorisation from the right person. Testing without authorisation from the system owner can be unlawful. Make sure the person signing actually has authority over every system in scope, including cloud tenants.
- A contract check. Many MSP agreements require notice before third-party testing, restrict scanning of shared infrastructure, or exclude liability for outages caused by testers. Read it before you scope the test.
- Shared infrastructure exclusions. If your MSP hosts multiple clients on the same platforms, testing those can affect other customers. Limit scope to systems that are yours alone.
- Rules of engagement. In-scope targets, forbidden actions such as denial of service or data destruction, testing windows, and what testers do if they find sensitive data.
- A trusted agent. NIST notes that some organisations designate a trusted third party so that response actions are not taken without first verifying whether an attack is real. That person needs authority to call the MSP and say “this is a test” if things escalate.
- A stop condition. If the MSP begins isolating critical systems or contacting authorities, the trusted agent intervenes.
Cloud platforms have their own rules
If your environment runs on Microsoft 365, Azure, AWS or Google Cloud, testers must follow those providers’ penetration testing rules as well as your own authorisation. We covered Microsoft’s rules in whether it is worth pen testing Office 365.
How to judge the result fairly
The point is to learn, not to catch someone out. Before the test, write down what the MSP contractually committed to detect and how quickly. Afterwards, compare:
- Which tester actions generated alerts in the MSP’s tools
- Which alerts were escalated to you, and how fast
- Whether containment actions matched the agreed authority
- Whether the MSP’s monthly report reflected what actually happened
Then share the findings with the MSP. A good provider will want them. A provider that responds defensively to evidence tells you something too. If you are reviewing what an outsourced SOC should escalate, see whether your SOC should report RDP brute force attempts.
When not to run a covert test
- Your contract with the MSP forbids it and you have not renegotiated.
- Critical systems have no recent tested backups.
- You have never run an announced test, so basic vulnerabilities are still unknown.
- No one senior is available as a trusted agent during the testing window.
A hypothetical sequence that works: a 200-person company runs an announced external and internal penetration test with its MSP first, fixes the findings, then six months later commissions a short covert exercise focused on detection, with the CFO as the trusted agent.
Related reading
- Do Retainer MSPs Exist? How to Buy Block Hours or Co-Managed IT
- Buying Sophos + Zscaler + Cisco Umbrella as one bundle: how a Brisbane CBD MSP cut its vendor sprawl
- Offshore Users on US Virtual Desktops: How to Reduce Latency You Cannot Eliminate
Testing your defences without breaking your relationships
Whether you need an announced penetration test or a carefully governed covert exercise, the scoping and rules of engagement matter as much as the testing. AB7 Solutions’ cybersecurity team provides vulnerability assessment and penetration testing (VAPT) and detection-focused testing, including rules of engagement, cloud provider compliance, trusted-agent coordination and a clear comparison of what your MSP detected against what we did. If an announced test is the right first step, we will recommend that.
Tell us what your MSP is contracted to monitor and what you want to learn, and we will propose the right kind of test.
Email: ab@ab7solutions.com | director@ab7solutions.com
Phone: +91 9878067778 | +1 321 341 7733
Website: www.ab7solutions.com
Sources: NIST SP 800-115, Technical Guide to Information Security Testing and Assessment. This article is general information, not legal advice.
Related AB7 service: cybersecurity services (managed SOC, VAPT).
[…] If you are commissioning a test, see how to buy a penetration test and not an automated scan, and for testing your MSP’s detection, whether to pen test your MSP without telling them. […]