Penetration testing for MSPs › In your service catalogue
Ask most MSPs how many penetration tests they placed last year and you get a number between two and eight. Ask how many are in the catalogue as a defined service with a price and a renewal date and the answer is usually none. The work is being done either way. One version builds a recurring line and the other is an administrative favour that generates a bit of project work by accident.
This is about the second becoming the first. It is not about selling more testing to clients who do not need it, which is a bad idea and easy to spot.
Why reactive placement does not accumulate
When testing arrives as a forwarded email, four things follow. The scope is set by whatever the client’s counterparty asked for, so you cannot standardise it. The timing is set by someone else’s deadline, so it lands in whatever week it lands. The price is a pass-through with a small uplift, because you had no basis to price it any other way. And it produces a report that generates remediation work nobody planned capacity for.
None of that compounds. Next year the same client forwards a similar email, and you do it all again from nothing. The fix is not a bigger margin on the pass-through. It is moving the decision from the client’s counterparty to your own account planning.
Annual is the right default
Annual testing of the internet-facing estate, plus a test after any significant change, is the cadence most insurers, questionnaires and frameworks are built around, and it is what most small and mid-sized clients actually need. More frequent testing makes sense where the client ships software continuously or where a specific system carries unusual risk. Less frequent means the report is out of date the moment anybody asks for it, and a lot of requirements name a maximum report age of twelve months.
Set it as the default in your catalogue and make the exceptions deliberate. A client with a quarterly release cycle and a public API is a different conversation from a twelve-person practice with a website and an Office tenant, and the catalogue should have room for both without you rescoping from scratch each time.
When in the client year to sell it
This is the part that separates a catalogue line from a hopeful one. Testing sells against a date somebody else has set, so build your sales calendar around those dates rather than around your own quarter ends.
| Trigger | When to raise it | Why it converts |
|---|---|---|
| Cyber insurance renewal | Three months before | Renewal questionnaires increasingly ask about testing, and a client who answers no at renewal is negotiating from a weaker position. |
| Tender season in the client’s sector | Two to three months before submission deadlines | A report cannot be produced in the week a bid is due, and a missing one loses marks or disqualifies. |
| Cyber Essentials renewal | At the same time as the certification | The client is already thinking about security spend and already has the budget conversation open. |
| A customer’s annual supplier review | When the questionnaire arrives | The deadline is real, external and not negotiable by you or the client. |
| A major change you are delivering | At project scoping | Testing after a migration or a new public service is easiest to justify while the project budget is still open. |
| Defence Cyber Certification, for MoD-linked clients | Now, given the 31 December 2026 deadline for industry partners | Def Stan 05-138 Issue 4 requires Cyber Essentials before any DCC level can be awarded, Level 0 included, and the date is not going to move. |
Keeping those six dates per client in the same system as your licence renewals costs almost nothing and changes the conversation from reactive to scheduled. It also stops the situation where three clients all need testing in the same fortnight because their insurers renew in April.
What the catalogue line should contain
Sell a programme rather than a report. Four components cover most cases and each one is separately defensible to a client who asks what they are paying for.
The test itself
Scoped annually against a standing target list you maintain, not rebuilt from scratch each year. Because you keep the list, the second year’s scoping is an hour rather than a week.
The readout
Your time reading the report, categorising the findings and presenting them to the client with a plan. This is a real deliverable and it is the one clients value most, because a report without interpretation is a PDF.
The remediation
Quoted separately, from the findings, and the largest component by value. Do not fold it into the fixed price: you cannot know what the test will find, and a fixed price that absorbs unknown remediation is a fixed price you will regret.
The retest
Scheduled at the point the remediation is accepted rather than left open. This is what converts fixed findings into evidence a third party will accept, and it is the component most often forgotten.
The arithmetic, in terms you can publish
Partner terms are negotiated and are not on a public page, so here is the sum done against published direct prices, which is the comparison your client could make anyway.
A fixed-fee external infrastructure test up to ten IP addresses is £3,000 plus VAT direct. A CMS website test, unauthenticated, is £2,500 plus VAT. A retest is £500 plus VAT, urgent turnaround £400, an additional IP block £500. Those are the numbers a client will find if they look, and they set the ceiling on what the test component of your line can carry.
The components around it are not constrained that way. The readout is your time and it is not comparable to anything. The remediation is priced on your rates against a list of work an independent party has justified. On most engagements those two together are larger than the test, which is why a catalogue line built only on reselling the test is competing on the one element with a public reference price.
How banked days change it
Per-test quoting is fine at one or two a year. Past that, every engagement carries its own commercial conversation, and short-notice work is hard because the procurement step sits in front of the testing step.
Banked days means buying a quantity of tester-days in advance and then spending them wherever they are needed, across whichever clients and engagements come up. Three things change when you buy that way.
- Mobilisation is faster. The commercial conversation has already happened, so a client with a three-week deadline is a scheduling question rather than a procurement one.
- You can quote with certainty. Your cost per day is known before the client asks, so you can give a price in the meeting instead of coming back next week.
- Small pieces become viable. A day of retesting, a half-day of scoping support on a complex target, or a short verification after a migration are all awkward to raise a separate order for and easy to draw from a block.
The constraint is utilisation. Days bought and not used are a cost with no revenue against them, so size the block against the testing you can actually see in your calendar rather than the testing you hope to sell. That is a genuine reason not to bank days in year one, and it is why most partners start per-test and move once the pipeline is real. Terms are negotiated and available on request.
What not to promise
Three things, all tempting and all expensive. Do not promise a clean report, because a competent test of a real estate finds things. Do not promise a date before you know who at the client can sign the authorisation, since that signature has to come from someone at the end client who can commit them. And do not bundle unlimited remediation into an annual fee, because the whole point of the test is that neither of you knows yet what it will find.
Standard lead time from agreed scope to testing is two to three weeks, often inside a week at short notice for a contained scope. Build that into what you commit to, and the catalogue line will survive contact with a client who leaves it late, which most of them will.
How many tests a year does a catalogue line need to be worth building?
The catalogue entry itself is worth writing even at two or three a year, because it stops you rescoping from nothing each time and it puts a renewal date in your system. Banked days are a separate decision and they need real volume behind them, because unused days are a cost with no revenue against them. Most partners start per-test and move once the pipeline is visible.
Should the remediation be inside the annual price?
No. Price the test, the readout and the retest as known quantities, and quote remediation separately from the findings. Neither you nor the client knows what a test will produce, and a fixed annual fee that absorbs unknown remediation transfers all of that risk to you for no additional margin.
When is the best time in the year to raise testing with a client?
Three months before their cyber insurance renewal, at their Cyber Essentials renewal, or two to three months before the tender deadlines in their sector. Testing sells against a date somebody else set. Keeping those dates per client in the same place as your licence renewals turns the conversation from reactive to scheduled.
Can we place certification through the same arrangement?
Yes. We are an appointed IASME Certification Body for Cyber Essentials and IASME Cyber Assurance Levels 1 and 2, we begin assessing Cyber Essentials Plus in late October 2026, and we are a Defence Cyber Certification body for Level 0. Clients holding MoD contracts are working to 31 December 2026, and no DCC level is available to them, Level 0 included, without Cyber Essentials first.
Terms for a catalogue line
Tell us how many tests a year you can see in your calendar and what your clients look like. You will get partner terms, and an honest view on whether banked days make sense for your volume yet, back in writing.