Adding Penetration Testing to an MSP or MSSP

An MSP or MSSP can add penetration testing well if it settles three things first: how it stays independent of the systems it manages, where qualified testers will come from, and how testing fits the managed relationship it already has, from delivery to tickets to retests. Get those right and testing deepens the relationship. Get them wrong and a client’s auditor questions every report you produce.

Independence comes first

A managed service provider that tests its own clients is, in part, testing its own work: the firewall rules its engineers wrote, the patching its team schedules, the monitoring its analysts watch. Auditors and careful buyers ask who carried out a test and whether they were independent of what was tested, and “the same company that runs it” needs a good answer.

The answer is structure rather than reassurance. Keep testers in a team separate from the engineers who manage client systems, with their own reporting line. Say in each report what the provider manages, so the reader can weigh the result. Have retests carried out by the testers, never by the engineers who made the fix. And for systems your own team designed and built, consider having a partner test them, so nobody is marking their own homework.

Build, partner or subcontract

Route	Speed to the first engagement	Margin	Control of quality	What to watch
Build a team	Slowest	Highest once testers are busy	Full	Keeping testers utilised between engagements
Refer to a partner	Fastest	A referral fee at most	None	The client relationship moving to the partner
Subcontract under your brand	Fast	In between	Through your own review	The report reading as yours, not the partner’s

Many providers start by subcontracting under their own brand and build a team once demand is steady enough to keep testers busy. Subcontracting well has its own rules, chiefly that the report the client receives is yours in format, voice and review; subcontracting a test and keeping the report yours covers them.

Accreditation, insurance and authorisation

In the UK no law requires a penetration testing accreditation, but buyers do. Many private sector and regulated clients ask for CREST accreditation or certified testers, and for UK central government systems the NCSC says testing should be done by companies in its CHECK scheme, which it strongly recommends to other public bodies too; CHECK vs CREST sets out which matters for whom. Check that your professional indemnity and cyber insurance cover testing explicitly, since a policy written for managed services may not.

Authorisation needs particular care. Managing a client’s systems does not authorise you to attack them. Every test needs written authorisation from somebody at the client with the authority to give it, naming the scope and the dates, and your own engineers’ administrative access is not a substitute. A penetration test authorisation letter sets out what it should say.

Your own security operations will see the test

A provider that monitors its clients will watch its own testers attack them. Decide in advance what the monitoring team is told. If the test is meant to measure detection, the analysts should not know it is happening, and somebody senior outside the team holds the testing schedule so that a real incident during the test can be told apart from the test itself. If detection is not being measured, tell the analysts the dates and source addresses so they do not spend a day investigating your own testers.

Either way, write the arrangement into the rules of engagement, with named contacts on both sides who can pause testing at once if something unexpected happens to a live service. A client’s system going down during a test is bad; going down while their provider’s analysts and testers each assume the other is responsible is worse.

What changes in your contracts

A managed service contract rarely covers testing. Testing needs its own statement of work for each engagement, with the scope, the dates, the testing positions and what is out of bounds, and its own terms on liability, since testing carries risks to the client’s systems that managing them does not. Keep the two agreements separate even when they are billed together, so that a dispute about one never has to be settled by reading the other.

Fitting testing into the managed service

The advantage a provider has over a standalone testing firm is the relationship. Use it. Testing can be part of the contract as a programme, such as an external test each quarter and a full test each year, rather than a series of one-off purchases; PTaaS for pentest firms covers selling it that way.

Findings can flow into the same ticketing your service desk already works from, which shortens the path from finding to fix. The independence rule still applies here: your engineers fix, and your testers confirm the fix.

Pricing it

One-off tests are usually priced from the scope, by the day. Recurring testing can sit inside the managed contract as a fixed fee for a defined programme of tests and retests, which clients find easier to budget for and which smooths your own utilisation. Whichever you choose, price the work, never the number of findings, or you reward the wrong thing.

Reporting under your own name

Clients should experience testing as part of the service they already buy: their reports and findings in a portal under your brand, email from your own domain, and the same people they already deal with. When a partner does the testing, their testers should appear to the client as part of your team, working in your template and through your review.