Operating manual · UK MSPs

The MSP Playbook for External Attack Surface Monitoring

By Nathan Hill-Haimes · Published 24 September 2026 Updated

Disclosure

This playbook is published by SurfaceLoop, which sells an EASM product and therefore has a commercial interest in MSPs offering this service. It is written to be run on any EASM tool: no step below depends on ours, tool selection is delegated to our vendor-neutral buyer's guide, and SurfaceLoop is confined to one clearly-labelled section at the end. Nothing here is legal advice; the authorisation section describes the questions to put to your own adviser.

Why does external monitoring fit the MSP model?

Most security services an MSP can add are either labour-heavy, need something installed at the client, or produce nothing the client can see until the day something goes wrong. External attack surface monitoring is unusual in avoiding all three, which is why it keeps appearing in MSP service catalogues rather than staying an in-house security team's tool.

It is recurring by nature, not by contract trick

A client's external estate changes without anyone deciding it should. A supplier stands up a microsite, a certificate renews or fails to, a firewall rule opened for a weekend project stays open, a subdomain points at a service that was cancelled six months ago. The work is genuinely continuous, so the monthly fee is not a payment plan for a one-off exercise. That distinction matters when a client's finance director asks what the recurring charge is actually for.

Nothing is deployed at the client

External-only scanning needs no agent, no credentials, no firewall exception and no change window. In practical terms that means onboarding a client is an afternoon of paperwork and DNS verification rather than a project, and a client who is nervous about letting you deeper into their environment has very little to refuse. It also means you can prove the service on one client before you build a catalogue item around it.

It produces something every month

Backup and patching are invisible when they work. External monitoring produces a dated artefact -- what we checked, what changed, what we closed, what is open and why -- that lands in an inbox whether or not anything went wrong. Over a year that is twelve pieces of evidence that your service does something, arriving in advance of the renewal conversation rather than being assembled during it.

It differentiates you against break-fix

A break-fix competitor can match your hourly rate and often your response time. What they structurally cannot do is tell a prospect what that prospect currently exposes to the internet, because nobody is paying them to look. A first scan on a prospect's own domains -- run only with their written permission, see authorisation below -- is the most concrete sales conversation available to an MSP, because it is about their estate rather than your capability slide.

The honest counterweight: this service is easy to sell and easy to deliver badly. The failure mode is not technical. It is an MSP that forwards raw scanner output, absorbs unbounded remediation work under a fixed fee, and cancels the service in month eight having lost money on it. The rest of this playbook is mostly about avoiding that.

What should a managed EASM service actually include?

Design the service before you price it. Every row below is a decision that gets made by accident if it is not made deliberately -- usually in the middle of an awkward conversation with a client who has a different recollection. Settle them once, in a service schedule you reuse.

Components of a managed external attack surface service, the decision to make for each, and the common failure
Component Decide this before you sell it What goes wrong if you do not
Scoping and asset inventory Which apex domains, subdomains, public IP ranges and brands are in scope, named in the service schedule. Scope by domain rather than by asset count, so discovery finding more does not reopen the commercial conversation. Scope agreed verbally as "their stuff", then an argument in month three about whether the parent company's domain was ever included.
Written authorisation to scan A signed clause or schedule naming the scope, the activity, the authorising person and their role, and how the client revokes it. Dated, stored, and re-confirmed when scope changes. An email thread with "yeah go ahead" from someone who did not have the authority to give it, covering a domain the client does not actually control.
Ownership verification A technical check that the client controls each asset -- a DNS TXT record you place, registrar or DNS-zone access you already hold, or written confirmation from the hosting provider -- before the first scan touches it. Scanning a lookalike domain the client mentioned but never registered, which belongs to somebody else entirely.
Scan cadence The interval you will contractually commit to, which should be the tool's floor and not its marketing word. Distinguish scheduled rescans from change-triggered alerting on new assets. Selling "continuous monitoring" on a plan that in practice rescans monthly, then being asked what "continuous" meant after an incident.
Triage responsibility Who reads raw findings, who validates them, who decides severity in the client's context, and what SLA applies to that decision rather than to the fix. Findings forwarded to the client unfiltered. The client cannot triage them, does nothing, and concludes the service is noise.
Escalation path What counts as out-of-cycle: a named severity threshold, who is called, in what order, out of hours or not, and what you are authorised to change without asking first. A critical exposure discovered on a Friday evening sitting in a shared mailbox until Monday, because nobody agreed it was anybody's.
Reporting rhythm A fixed date, a fixed format, a named recipient, and a quarterly or annual review with a decision-maker rather than an IT contact. Reports sent when there is something impressive to say, which trains the client to read a missing report as good news.
Remediation boundary In writing: what you fix under the monitoring fee, what you fix under the existing managed contract, what is chargeable project work, and what is the client's own or a third party's. "You monitor it, so surely you fix it" -- the single most common margin leak in this service.
Exceptions and suppression How an accepted risk is recorded, who signs it off on the client side, and when it is reviewed again. Accepted findings should stay visible as accepted, not vanish. Awkward findings suppressed in the tool by an engineer, so nobody can later show the client chose to live with them.
Offboarding What happens at termination: scanning stops on a stated date, authorisation lapses, findings history is exported to the client, tenant data is deleted on a stated timetable. Scanning a former client's estate for months after the contract ended, with no live authorisation covering it.

Two of these carry more weight than the rest. The remediation boundary decides whether the service makes money, and authorisation decides whether you should be running it at all. Both belong in the contract, not in a handover call.

How should you charge for it?

Four models are in common use. None is wrong, but they fail in different places, and the trade-off column is the part worth arguing about internally before you publish a price.

Four commercial models for a managed EASM service, where each fits, and the trade-off
Model How it works Where it fits Trade-off
Cost-plus resale You pay the tool's per-client price and add a stated margin or handling fee. The client sees a line item that maps to a product they could in principle buy themselves. Clients who want transparency, and MSPs testing demand before committing to a service wrapper. The weakest model. It prices the licence, not your work, so the triage and reporting labour is unpaid. It also invites the client to compare your mark-up with the vendor's list price and cut you out.
Bundled into an existing managed-security tier External monitoring becomes a named component of your mid or top security tier, funded by the tier price and used as the reason the tier exists. MSPs with an established tiered catalogue and enough clients on the higher tiers to absorb a flat per-client tool cost. Cleanest to sell and hardest to cost. Because the tool bills per client, every client on that tier carries the cost whether or not they engage with the output. Model take-up at 100%, not at your optimistic guess, and check the tier still clears margin at the smallest client in it.
Per-client flat fee A published monthly figure per client for monitoring, triage and reporting, sold as its own service alongside the managed contract. Most smaller UK MSPs. It matches the shape of per-client tool pricing, so cost of goods is fixed and known before discovery runs. You must hold the line on the remediation boundary, because the flat fee covers finding and explaining, not fixing. Very small clients are the hard case: a flat tool cost per client does not shrink for a five-person business, so there is a floor below which the service cannot be sold profitably.
Compliance or insurance add-on Positioned as evidence production -- Cyber Essentials preparation, insurer questionnaires, client supply-chain audits -- and often sold with an annual or quarterly review rather than monthly. Clients with a forcing function: a renewal, a certification date, a customer questionnaire they cannot answer. Event-driven demand. It sells well into a deadline and lapses afterwards unless you convert it to continuous monitoring, and it raises expectations you can produce audit-grade evidence on request. Be clear that no tool certifies anyone.

Margin mechanics, honestly

EASM tools are overwhelmingly priced per organisation: per client, per asset count, or per target. That has a specific consequence for an MSP. Unlike an RMM seat or a mailbox licence, your cost of goods does not fall as the client gets smaller, and in metered models it rises when discovery does its job. So the arithmetic is:

  • Tool cost is a floor, not a variable. A flat per-client licence sets the minimum viable price for the service and therefore the minimum viable client. If the licence is a meaningful fraction of what a five-person client pays you in total, this service is not for that client at this price.
  • Your margin is triage time. Two clients on identical licences can differ by an order of magnitude in labour, depending on estate size, how much of it is third-party, and how much the client engages. Track hours per client for the first quarter; the distribution will surprise you.
  • Month one loses money. The initial backlog is the heaviest triage you will ever do on that client. Either price a separate onboarding fee for it or accept a deliberately unprofitable first month, but decide which -- unpriced onboarding is how a per-client flat fee stops clearing.
  • Metered pricing and MSP margin sit badly together. If the bill tracks discovered assets, then a client acquiring a business or launching a campaign microsite changes your cost after you have fixed your price. Either pass metered costs through explicitly or choose a tool whose price you can forecast. The four pricing models in the buyer's guide set out what you are choosing between.
  • Do not build the business case on tool mark-up. Reselling a licence at a margin is competing with the vendor's own website. Selling triage, context and a monthly report is competing with nobody, because the client cannot buy that anywhere at your price.

Do you need written authorisation to scan a client?

Yes. This is the section of the playbook people skim and should not. Scanning infrastructure you do not own, without permission from someone entitled to grant it, is a legal problem rather than an etiquette problem -- and an MSP is exposed to it across every client simultaneously rather than one at a time.

In the UK the relevant statute is the Computer Misuse Act 1990, which makes unauthorised access to computer material an offence. Authorisation is what separates a legitimate security assessment from an offence, and it has to come from someone with the authority to give it for the systems in scope. Note what that sentence does not say: it does not say a friendly verbal go-ahead, it does not say a client contact who happens to be technical, and it does not say a domain the client mentioned in a meeting. Nothing here is legal advice -- these are the points to take to your own solicitor when your service schedule is drafted.

What documented authorisation needs to contain

  • Named scope. The apex domains, subdomains, hostnames and public IP addresses or ranges covered, plus how newly discovered assets under an in-scope domain are treated. Discovery will find things nobody listed, so the authorisation has to anticipate that rather than be silently exceeded by it.
  • Named activity, and its limits. That the assessment is external and non-intrusive: reconnaissance, service and version identification, configuration and certificate checks, DNS and email authentication checks. And explicitly what it excludes: no exploitation of findings, no credential guessing or brute-forcing, no denial-of-service or load testing, no social engineering, no access to data.
  • The authorising person, by name and role. Someone who can bind the client -- a director, or an IT decision-maker with documented delegated authority. Record the date. If the person who signed leaves, re-confirm.
  • Duration and revocation. That authorisation runs for the term of the service, that the client can withdraw it in writing, and that scanning stops within a stated period of withdrawal. An authorisation with no exit is one a client is right to hesitate over.
  • Third-party acknowledgement. That the client confirms it owns or controls the listed assets, and that where an asset is hosted or operated by someone else the client is responsible for telling you so, so that permission can be sought.
  • Data handling. Which EASM tool you use and that it processes findings on the client's behalf, so the vendor is disclosed as a sub-processor. Scan output is a map of the client's weaknesses -- treat it as confidential whether or not it contains personal data, and make sure your UK GDPR processor terms cover it.

The three traps

Assets the client does not own. The single most common way an MSP scans something it should not. A client will hand over a domain list containing a lookalike domain they never registered, a former trading name now owned by somebody else, a supplier's platform they use but do not control, or a shared-hosting IP carrying dozens of other businesses. Verify ownership technically before the first scan, and when an in-scope domain resolves to infrastructure the client does not control, stop and ask.

Provider terms. Hosting providers, cloud platforms and CDNs set their own acceptable-use rules about security testing of assets on their infrastructure, and they are not identical. Check the terms that apply to the client's actual hosting before you start, rather than after a provider notices traffic it does not like. Being authorised by your client is not automatically being authorised by their provider.

Prospect scanning. A first scan on a prospect's estate is a powerful sales tool and the easiest place to get this wrong. The temptation is to run it before the conversation and arrive with findings. Do not. Get the same written scope and authorisation you would for a client, even for a two-week trial, even when the prospect is keen. If a prospect will not sign a one-page scanning authorisation, that is useful information about them, and the alternative is running an unauthorised scan on a company that has not agreed to anything.

Finally, keep the record. Dated authorisations, scope changes, and the date scanning stopped at offboarding, filed per client. The point of the paperwork is not the paperwork; it is that a year later you can say precisely what you were permitted to do, by whom, and when.

How do you onboard a client? A runbook

Nine steps, in order. Steps one to three are paperwork and must precede any scanning. Budget two to four weeks from signature to the first client-facing report, most of which is triage rather than waiting for the tool.

  1. Agree scope in writing. Build the asset list from three sources, not one: what the client tells you, what your own records show, and the domain registrar and DNS records you can see. Scope by domain rather than by asset count so discovery does not reopen the commercial terms. Write down what is excluded as well as what is included, and note which assets are known to be third-party operated.
  2. Get written authorisation to scan. The signed schedule described above: named scope, named activity and its exclusions, the authorising person and role, duration and revocation, third-party acknowledgement, data handling. Nothing is scanned until this is signed and filed. If your standard MSA does not already carry a scanning clause, have one drafted once and reuse it.
  3. Verify ownership of every asset. A DNS TXT record you place, DNS or registrar access you already administer, or written confirmation from whoever operates the asset. Anything that fails verification comes out of scope until it is resolved -- it does not go in as a maybe. This step catches the lookalike domains and the supplier-controlled platforms before they become a problem.
  4. Configure the tool and the alerting before the first scan. Tenant or subscription per client, so findings cannot cross between clients. Alert routing to your team rather than to the client, at least until you have triaged a full cycle. Set the severity threshold that triggers your escalation path. Record the scan schedule and your source addresses so you can answer the hosting-provider question later.
  5. Run the baseline scan, and let discovery finish. Do not report on a partial first run. When it completes, record two numbers before you look at any finding: how many assets the client listed, and how many the tool found. That delta is the most persuasive line in your first report and the clearest justification for the service.
  6. Triage the initial backlog before the client sees anything. Expect it to be large. Validate, deduplicate, discard the informational noise, re-rate in the client's context, and group findings by the fix rather than by the asset. Sort what remains into the four buckets in the triage section. This is the step MSPs skip and then regret: a raw first export is the fastest way to make a client feel attacked by the service they just bought.
  7. Handle anything urgent immediately, out of band. If the baseline turns up an exposed admin interface, default credentials, or a critical CVE on a live service, that is a phone call today under your escalation path -- not a line in a report in three weeks. Getting this right once is worth more to the client relationship than the next six reports.
  8. Hold a scoping-out session on remediation. Walk the triaged list with the client and agree, item by item, what you will fix, what they or a third party will fix, what is chargeable, and what is being accepted with a written rationale and a review date. Leave that meeting with an agreed remediation boundary and a signed-off accepted-risk list. This is the meeting that protects the margin for the rest of the contract.
  9. Set the reporting cadence and name the recipient. A fixed monthly date, a fixed format, a named person, plus a quarterly review with someone who makes decisions. Tell the client explicitly what a quiet month will look like, before they get one. Then put the next quarterly review in the calendar while you are all still in the room.

One warning about step six. Almost every client's first scan produces findings, and the volume says nothing about that client's competence -- it reflects how long nobody had looked from the outside.

Frame it that way when you present it, because a client who feels accused in month one is a client who stops reading in month four. Any competent external scan across a cohort of UK SMEs would surface a similar picture, which is rather the point: the first report is a measure of visibility, not of negligence.

How do you triage the first scan without drowning?

Triage is the service. The tool finds things; the reason a client pays you rather than buying a licence is that somebody decides what each finding means on their estate and who is going to do something about it. Run every finding through the same three questions -- is it real, does it matter here, and whose is it -- then drop it into one of four buckets.

Four triage buckets for external scan findings, with target window, owner, and what the client sees
Bucket What lands here Target window Who owns it What the client sees
Fix now Exposures that are directly exploitable, indicate a live compromise, or expose an administrative interface or a service that should never have been public: default credentials, an exposed admin panel or database port, a critical CVE on an internet-facing service, a subdomain takeover. Same day, out of cycle. This is what the escalation path exists for. You, where the asset is in your managed scope and the change is within your authority. Otherwise you raise it and the client's own provider acts, with you chasing. A phone call, then a written note. Not a line in next month's report.
Schedule Real issues with no immediate exploitation path or where the fix needs a change window: expiring or mismatched certificates, missing HTTP security headers, unsupported software versions, SPF, DKIM and DMARC gaps, unnecessary open ports on non-administrative services. Next available change window, with a named target date in the report. You, batched into planned work. The single most useful thing you can do here is group findings by fix rather than by asset -- one DNS change often closes a dozen findings. A dated plan in the monthly report, and visible movement month to month.
Accept with rationale Findings that are technically valid but not worth acting on here: a header missing from a static marketing site, a legacy service the business genuinely needs, a low-severity disclosure on an asset due for decommissioning. Decided once, recorded, reviewed at the quarterly or annual review. The client decides; you write the rationale and the review date. Acceptance must be the client's choice, on the record, not your silent suppression. A short accepted-risk list in the report, with the reason and the review date next to each entry.
Not ours to fix Assets outside your remit: a marketing agency's microsite, a SaaS vendor's subdomain, a parent company's range, an asset the client does not actually own. Raised within the reporting cycle, then tracked as an open dependency. The client owns the third-party conversation. You provide the finding, the plain-English explanation and the evidence they need to forward it. Listed separately from your own work, so the report does not make your service look stalled by somebody else's inaction.

Four rules that make triage survivable at scale

Group by fix, not by finding. A scanner reports per asset. A change is made per system. One SPF correction or one reverse-proxy header change can close dozens of findings at once, and a remediation plan organised around changes is both shorter to write and far easier for a client to approve than the same content organised around assets.

Start with the cheap categories. DNS and email authentication gaps are usually the highest ratio of risk reduction to effort on an SME estate: no downtime, no change window, no code, and they are extremely common.

That makes DMARC, SPF and DKIM the natural first month of remediation on most clients: visible progress, low risk, and a finding the client can understand without a security background because it is about their email being impersonated.

Never suppress silently. If a finding is not going to be fixed, it is accepted -- and acceptance is a client decision with a named owner, a written reason and a review date. An engineer quietly dismissing awkward findings in the tool destroys the one thing this service produces, which is a defensible record.

Keep a false-positive log per client. Every tool raises some. Record what you dismissed and why, so the same finding does not consume triage time every cycle and so a new engineer does not re-escalate something settled in March. If the same false positive keeps reappearing, that is a question for your vendor and a criterion in your next tool review.

What belongs in the monthly client report?

The report is the product the client actually experiences. Two pages, the same shape every month, readable by someone who is not technical. If it takes you more than an hour per client after the first quarter, the format is wrong.

  1. Scope restated. Domains and assets monitored, and the count of assets, so scope creep is visible and the report stands alone if it is forwarded to an insurer or a customer.
  2. What changed since last month. New findings, closed findings, newly discovered assets, assets that disappeared. This is the top of the report, not the bottom.
  3. Anything escalated, and what happened. Out-of-cycle items, when they were raised, what was done, and how long it took.
  4. Open items, by owner. Split into yours, the client's, and third-party dependencies, each with a target date. The client should be able to see their own homework in one glance.
  5. Accepted risks. The standing list, with the reason and the review date beside each. Short, but never absent.
  6. Trend. Findings closed cumulatively, and open findings by age, over at least six months.
  7. What we need from you. One short list. If this section is empty, say that too.

Show change, not counts

Raw totals are a trap, because they move for reasons that have nothing to do with the client's security posture. Improve your discovery, add a brand, onboard an acquisition, and the open finding count rises while the estate is objectively better managed. A client who has been trained to read that number as a score will read progress as failure, and you will find yourself arguing against your own tool.

Report deltas and durations instead: findings closed this month, cumulative closed since onboarding, mean age of open findings, time from detection to triage decision, and the count of newly discovered assets. Those numbers all improve when you do your job and none of them get worse because you looked harder. If you do show a total, show it alongside the asset count so the denominator is visible.

The month nothing changed

It will happen, often around month four once the backlog is cleared, and it is the moment the service feels most cancellable. Handle it directly rather than hiding it:

  • Say it in the first line. "Four scans run across 38 assets. No new exposure. Two items remain open, both awaiting your change window." A confident quiet report reads as control; a padded one reads as filler.
  • Report the checking as the deliverable. Scans run, assets covered, categories checked. The client is buying assurance, and assurance has evidence even when nothing happened.
  • Lean on the cumulative line. A flat month still sits on a rising fixed-over-time curve. That chart is why you started keeping it in month one.
  • Use the space for something useful. A scope review, a spot check on an asset you have not examined closely, a look at a supplier domain, or progress on the accepted-risk list. Quiet months are when improvement work actually gets done.
  • Never manufacture findings. Promoting informational noise to fill a page is the fastest way to teach a client to skim -- and the month you genuinely need them to act, they will skim that one too.

If a client is going to be asked about their external posture by an insurer, a customer or a Cyber Essentials assessor, make sure the report is exportable and dated in a form they can hand over. A monthly report that doubles as evidence is worth noticeably more than one that only reassures.

What will clients push back on, and what do you say?

These come up in roughly this order. The answers below are deliberately honest rather than persuasive: a client talked into this service will cancel it, and the objection that is hardest to answer -- "nothing happened, why am I paying?" -- only gets easier if you set expectations before it arrives.

Common client objections to a managed external monitoring service, what sits behind each, and an honest answer
What they say What is behind it An honest answer
"We already have a firewall and antivirus." A reasonable belief that security is a product you install, and no mental model for assets nobody knew about. Both defend things you know you have. This answers a different question: what is reachable from the internet that nobody on your side has looked at. The first scan usually names two or three assets neither of us had on a list, and that is the part a firewall cannot help with.
"Isn't this already your job? Why is it extra?" A fair challenge, and often a sign your existing contract is vague about security scope. Your contract covers keeping agreed systems running and patched. This adds continuous discovery of things outside that list, monthly evidence, and someone reading the output. If you would rather it were inside the existing fee, we can do that at the next renewal -- it is a cost either way, so let us put it somewhere visible.
"We had a penetration test last year." Confusion between a point-in-time engagement and continuous monitoring, sometimes encouraged by whoever sold the test. A pen test goes deep on a scope on a date, and a good one is worth more than any scan. Monitoring goes shallow across everything, every cycle. The test told you about the estate as it was that week; this tells you when something changes. Most estates change several times a year.
"Will scanning break anything, or upset our hosting provider?" A genuine operational worry, and often a memory of a badly run scan. The scanning is external and non-intrusive: no exploitation, no credential testing, no load testing. We will tell you the source addresses and the schedule, we check your hosting provider's acceptable-use terms before we start, and you can revoke authorisation in writing at any time and scanning stops.
"Nothing was found this month. What am I paying for?" The structural problem with all preventative services, and usually a report that reads as an empty page. You are paying for the checking, and for the fact that it was quiet. Here is what ran, here is what is still open from earlier, and here is the fixed-over-time line. A quiet month on a changing estate is the product working -- and if quiet months keep coming, that is the right moment to widen the scope rather than cancel.
"If you write this down, does it count against us with our insurer?" A real commercial fear about creating a documented record of known weaknesses. Being able to show a monitored estate with a dated remediation record is usually the stronger position, and insurers increasingly ask about it. What creates exposure is a finding that was known and neither fixed nor formally accepted -- which is exactly why the accepted-risk list with your sign-off is part of the report.
"Can we just have the tool's login and do it ourselves?" Cost pressure, and a belief that the tool is the service. You can, and some clients should. Be clear about what you are taking on: reading every finding, deciding what matters on your estate, chasing third parties, and keeping the record. The licence is the cheap part. If nobody is going to own that work, a licence nobody logs into is worse value than no licence at all.

One conversation is worth having unprompted. Tell every client at onboarding that quiet months are the expected outcome and what a quiet report will look like. It costs you two sentences in month one and removes the most common cancellation reason in month nine.

Which tool should you run this on?

Every step in this playbook works on any competent EASM platform, which is why tool selection is not in it. Choose the platform separately, against a written rubric, using our vendor-neutral EASM buyer's guide for UK SMEs and MSPs, which carries the scoring rubric, the questions to ask on a demo call, the four pricing models and the UK procurement checks.

Four criteria in that rubric matter more to an MSP than to a single-business buyer, and it is worth reweighting before you evaluate anything:

  • Client separation. One client's assets and findings must never appear in another's view or report. Everything else is a preference; this is a requirement.
  • Cost forecastability per client. You are fixing a price for twelve months against a cost you do not control. Metered models put that risk on you.
  • Reporting you can send with minimal editing. Report assembly is the labour that decides how many clients one person can carry.
  • Authorisation and ownership verification built in. A tool that makes you prove control of a domain before scanning it is doing part of your compliance work for you.

Whatever you pick, evaluate it on two or three real client estates in parallel with the client's written authorisation in place, and count how many assets each tool finds that were not on the client's list. That single number tells you more than any feature matrix.

Where does SurfaceLoop fit, honestly?

Our own product · the one promotional section in this guide

SurfaceLoop is an external scanner with discovery included, plain-English remediation on every finding, and one published flat price per business. For a smaller MSP running this playbook across a book of UK SME clients, that shape helps in two specific ways: the cost of serving each client is fixed and known before discovery runs, so the per-client flat fee model above is simple arithmetic; and findings written for a non-specialist reader cut the report-writing labour that decides how many clients one engineer can carry.

What it is not, stated plainly because you will otherwise find out during an evaluation: there is no partner console, no white-label or rebranded client portal, and no multi-tenant billing across a portfolio. The clean model today is one plan per client, with your own reporting layer on top. If you run hundreds of tenants from a security operations centre, you want purpose-built MSSP tooling and this is not it. Our MSP use-case page sets out the same limits, and the MSP service page covers what the product does for client estates.

If you want to test the playbook rather than the pitch: take one real client, get the written authorisation from step two, and run a trial on their estate. The number to watch in week one is how many assets discovery finds that were not on the client's list -- that is the figure your whole service proposition rests on, whichever tool you end up buying.

Book a demo -- bring a client estate Compare tools first

Questions, answered

Something else? Email hello@surfaceloop.com and a person replies.

Do MSPs need written permission to scan a client's systems?

Yes, and it should be documented rather than verbal. In the UK, unauthorised access to computer material is an offence under the Computer Misuse Act 1990, and the thing that separates a legitimate security scan from an offence is authorisation from someone entitled to give it for the systems in scope. Get it in the contract or a signed schedule, name the exact scope and the activity, record who authorised it and their role, include a revocation route, and re-confirm it when scope changes or the contract renews. This is general guidance, not legal advice -- have your own terms reviewed.

What should an MSP charge for external attack surface monitoring?

Price the work, not the licence. The four workable models are cost-plus resale, bundling into an existing managed-security tier, a per-client flat fee, and a compliance or insurance add-on. For most smaller UK MSPs a per-client flat fee matches the shape of per-client tool pricing best: the cost of goods is fixed before discovery runs, so the margin question becomes how much triage and reporting labour each client consumes. Expect the first month of any client to be loss-making because of the initial backlog, and consider a separate onboarding fee for it.

Who is responsible for fixing what an external scan finds?

Whoever the service schedule says, which is why the remediation boundary has to be written down before the first report. A workable split is: you fix findings on assets already inside your managed scope, out-of-scope or third-party assets are raised and tracked but owned by the client, and anything requiring project work is quoted separately. Monitoring services that leave this implicit end up absorbing unbounded remediation labour under a fixed monthly fee.

How big is the first batch of findings likely to be?

Larger than the client expects. In SurfaceLoop's September 2026 scan of 1,083 UK SME internet-facing assets, 95.4% of domains had at least one open externally visible finding, and email authentication gaps were the single most common category. Plan the first month around triage rather than remediation: sort the backlog into fix-now, schedule and accept-with-rationale before you show the client anything, and never hand over a raw first export. The initial list is a measure of how long nobody looked, not a report card on your client.

How often should an MSP scan client estates?

Commit to the interval your tool actually guarantees on the plan you bought, and say so in the service schedule. Many entry and free tiers rescan weekly or monthly even when the marketing says continuous, so check the floor rather than the adjective. Separately, make sure newly discovered assets are scanned on discovery rather than waiting for the next cycle: new exposure usually arrives with a new asset, not with a change to an old one.

Do you need a multi-tenant platform to offer this as an MSP?

Not to start. Plenty of MSPs run the first handful of clients as separate tenants or separate subscriptions, with reporting assembled manually. What multi-tenancy buys you is scale: one login, per-client reporting without editing, and consolidated billing. The point at which manual operation stops working is usually somewhere around ten to fifteen clients, when the reporting labour per client becomes the limiting factor rather than the tool cost.

What do you report in a month where nothing changed?

Say so plainly, and report the checking as the deliverable: scans run, assets covered, no new exposure, plus what is still open from previous months and what you are waiting on from the client or a third party. Show the cumulative fixed-over-time figure so a flat month still sits on a rising line. Never pad a quiet month with low-value findings to make the report look busy -- it trains the client to skim, and the month you need them to read it they will.

Should the client see the raw tool output?

On request, yes, but it should not be the deliverable. Raw exports contain duplicates, informational findings, and severity ratings assigned without knowledge of the client's context -- all of which either alarm or bore the reader. Your value is the layer in between: verifying, deduplicating, re-rating in context, grouping by fix, and writing it in language the client's finance director can follow. If the raw export is the report, the client is right to ask why they are not buying the licence directly.

Published 24 September 2026 · Last updated 24 September 2026 · Written by Nathan Hill-Haimes, co-founder of AMVIA and SurfaceLoop. First-party statistics are drawn from the UK SME External Exposure Snapshot, September 2026, whose methodology is public. References to the Computer Misuse Act 1990 and to UK GDPR are provided for orientation and are not legal advice: have your own scanning authorisation and processor terms reviewed by a qualified adviser. This playbook may be quoted with attribution to SurfaceLoop.