What a Pentest Requires, Part 1: Licensing and Scope

Before you read a single finding, two things decide whether the document in front of you is a penetration test or an expensive PDF: whether the vendor was allowed to do the work, and whether they stayed inside the boundary you drew. So before testing starts, check the provider's status, get the authorization in writing, and be clear about what the buyer, the provider and any subcontractors are each responsible for.

This is the first part of a series on what a penetration test actually requires. Each part takes a few of those requirements, says what good looks like, and gives you the question to ask your vendor.

Who is even allowed to run a pentest

In Singapore, providers of penetration-testing services need a licence from the Cybersecurity Services Regulation Office (CSRO), and the register of licensed providers is public at csro.gov.sg. Checking it takes a minute.

Check every legal entity that delivers the service, including resellers and subcontractors where they take part. CSRO treats a business that only supplies software or tools differently from a service provider, and its FAQ explains an exemption for related companies. If the delivery model is unclear, ask CSRO.

Licensing, company accreditation and a tester's personal qualifications are three different checks. Find out which accreditation, if any, your procurement team or assessor requires, then check the provider's exact status. Ask for the reviewer by name, with their qualifications, so a challenged finding has an accountable person behind it. ManticoreAI, for its part, is on the CREST accreditation Pathway, which is a step toward company accreditation rather than accreditation itself.

Scope defines what the tester is authorised to touch

Once the vendor is allowed to test, scope decides what they are allowed to touch. This is the least glamorous part of an engagement and the one most likely to cause you a genuine legal problem.

Two application hostnames do not automatically authorize testing their hosting infrastructure or other virtual hosts on a shared server. Write down the actual hosts, ports, protocols, roles, permitted actions and exclusions. And make sure whoever signs the authorization has the authority to permit the work, including any conditions a hosting provider or other third party sets.

In a report I reviewed recently, the vendor pointed a scanner at the whole server and filed six findings against backend services that were never in scope. Then they used one of those issues to reach a hidden application on the same shared host, an application that plausibly belonged to a different customer entirely. A discovery like that should stop the test until someone with authority decides. The application scope never gave permission to investigate it.

Testing without authorization creates legal and operational risk for everyone involved. Who carries it depends on the facts, the authority given and the applicable law, and it does not automatically fall on the buyer alone.

Why practitioners are strict about this

I spent years at Trustwave and roughly one in five of my support calls was about scope. Not findings, not severity, scope. A consultant once hit a server that was not in scope by mistake, a genuine accident, and the client demanded we restart his background checks before he was allowed near their environment again. That is the reaction a real accident gets from a serious client.

So when a vendor scans outside the agreed boundary as a matter of routine, and reports the results as though extra coverage were a bonus, that is not enthusiasm. It tells you the engagement had no rules of engagement worth the name, and it means the next client, on the next test, gets the same treatment.

There is a version of this that is legitimate and worth knowing about. During a test we frequently find things sitting outside the boundary, backend services, a forgotten host on the same machine. The correct handling is to stop, tell the agreed contact and get permission before going further. If the observation goes in the report, it should be clearly marked as out of scope and unvalidated, not presented as a finding. Finding something is not the same as being allowed to test it.

The questions to ask

1. Which legal entity holds the licence, and can I see the number? Then check the public register yourself rather than taking the answer on trust.
2. Who signs the report, and what are their credentials? A named human with a certification, not a platform.
3. What exactly is in scope, written down, before anyone starts? Hostnames, ports, protocols, and an explicit statement about shared infrastructure and other virtual hosts.
4. What happens when you find something out of scope? The right answer is that they stop, notify the agreed contact and get permission before investigating further. Anything they record should be marked out of scope and unvalidated.

CSRO says that hiring an unlicensed provider is not itself an offence under the Cybersecurity Act, though it recommends using licensed providers. That question is separate from whether a test is authorized. Check both, and take legal advice if the engagement or the boundary is unclear.

Sources: the CSRO FAQ and licensing requirements, as of 20 October 2026.