Penetration testing is one of the easiest security services to buy badly. The deliverable is a document, the quality of that document is hard to assess if you are not a practitioner, and the cheapest quote is almost always an automated scan with a cover page. Buyers in Singapore and Malaysia frequently discover the difference only when an auditor or an enterprise customer reads the report and asks questions it cannot answer.
This is how to scope a test properly and how to tell, on receipt, whether you got one.
Scan, test, red team — three different purchases
Vulnerability scan
An automated tool enumerates known issues against known signatures. It is fast, cheap, and worth running continuously. It finds missing patches and obvious misconfiguration. It does not find business logic flaws, chained exploits, or broken authorisation, and it produces false positives that a human has to triage.
Penetration test
A qualified tester works against your system with defined scope and rules of engagement, using tooling where it helps and judgement where it matters. This is what finds the authorisation flaw that lets one tenant read another tenant's records — the class of issue that scanners structurally cannot detect, because it requires understanding what the application is supposed to do.
Red team exercise
An objective-based engagement against your organisation, usually without the defenders knowing, testing detection and response as much as the technology. Appropriate once you have a security operations capability worth testing. Buying this before you have fixed your known issues is expensive theatre.
Most organisations asking for "a pentest" need the second. Some need the first and have been sold the third.
Scoping: the questions to settle before quoting
- What exactly is in scope? Named hosts, domains, applications, mobile apps, APIs. Vague scope produces a vague test.
- How many distinct user roles? Testing an application with five permission levels is substantially more work than testing one with anonymous access only, and authorisation flaws are where the serious findings live. You want the tester to have credentials for every role.
- Black box, grey box, or white box? Grey box — tester gets credentials and a walkthrough, not source — is the right default for most applications. Pure black box spends your budget on reconnaissance you could have just told them.
- Production or staging? Staging is safer but only useful if it genuinely mirrors production configuration. A staging environment with debug enabled and different infrastructure tests something you do not run.
- Is a retest included? A test without a retest tells you what was broken, not that it is fixed. Auditors and enterprise customers usually want evidence of the latter.
- What are the rules of engagement? Testing window, escalation contact, what is explicitly out of bounds (denial of service, social engineering, third-party hosted services you do not own), and written authorisation from whoever can give it.
If a vendor quotes a fixed price without asking most of these, they have not scoped a test — they have priced a scan.
What a real report contains
When the report arrives, check it against this list before you accept it:
- An executive summary a non-technical director can act on. What is the risk to the business, what should be fixed first, what is the overall posture.
- Reproduction steps for every finding. Specific enough that your developer can reproduce it without contacting the tester. Request, payload, response, screenshot.
- Evidence of exploitation, not just detection. "Possible SQL injection" is a scanner output. "Extracted the following table names" is a finding.
- Severity with justification. A rating tied to reasoning about exploitability and impact in your context, not just a copied CVSS figure.
- Specific remediation advice. "Use parameterised queries in this handler" beats "implement input validation".
- What was tested and found clean. Negative results are part of the deliverable. A report that only lists findings tells you nothing about coverage.
- Methodology and a named tester. Which standard was followed, which tooling, and who did the work.
A twelve-page report that is entirely scanner output reformatted is recognisable: every finding cites a CVE, nothing references your application's own logic, and no finding required a second step.
Regional and compliance drivers
In Singapore and Malaysia, the trigger for a test is usually one of three things: a sectoral regulator's expectations, a customer's vendor security assessment, or a certification such as ISO 27001 or SOC 2 that requires evidence of regular technical testing. Each wants slightly different evidence.
Tell your vendor which one is driving the engagement before scoping. A test scoped for an internal risk exercise and a test scoped to satisfy an enterprise customer's questionnaire are not the same engagement, and discovering the gap after delivery means paying twice.
Cadence and what to do between tests
An annual test is the common baseline, with an additional test after any significant architectural change — a new authentication system, a move to a new cloud region, a major feature that handles money or personal data.
Between tests, the work that matters is unglamorous: dependency updates, automated scanning in your pipeline, log review, and actually closing the findings from the last report. Organisations that commission a test annually and close nothing are buying a document, not security.
See how we scope penetration testing and cybersecurity consulting, or talk to a senior engineer about what your scope should actually cover.