Penetration Testing: Types, Phases and How to Hire a Tester

A penetration test is an authorised attack on your own systems. You name the targets and the rules, a tester spends a fixed number of days trying to break in the way a real attacker would, and at the end you receive a report of what worked, how it worked, and how to close it.

NIST SP 800-115 defines it as "security testing in which assessors mimic real-world attacks to identify methods for circumventing the security features of an application, system, or network." The useful word there is methods. A pen test finds the path an attacker would take, which is often a chain of small weaknesses that no single scanner result would flag as serious.

This guide covers the service from the buyer's side: what it is, how an engagement runs, what to expect in the report, and how to choose and check a provider. If you want to become a tester, the ethical hacker roadmap covers skills and certifications in depth.

Pen test, scan, red team, bug bounty

Four services get confused because they all look for security weaknesses. They answer different questions.

Scans feed the ongoing work of finding and patching known weaknesses, which the vulnerability management lifecycle guide covers. A pen test is a point-in-time check that the program works and that nothing exploitable slipped through. A red team comes later, once the basics are sound and you want to test detection and response. A bug bounty runs alongside all of them, and bug bounty hunting explains it from the researcher's side.

NIST SP 800-115 draws the key line between the first two: "While vulnerability scanners check only for the possible existence of a vulnerability, the attack phase of a penetration test exploits the vulnerability to confirm its existence."

Black box, grey box, white box

The box describes how much the tester knows at the start.

• Black box. The tester gets a target (a domain, an IP range, a company name) and nothing else. It shows what an outsider with no inside knowledge can do, and spends a large share of the budget on discovery that you could have handed over.
• Grey box. The tester gets some access: normal user accounts for each role, API documentation, a network diagram. This is the usual recommendation because it puts the testing days into the parts an attacker would reach after a phishing email or a credential leak.
• White box. The tester gets full access: source code, architecture, configuration and admin accounts. It covers the most ground per day and suits high-value applications, at the cost of realism.

A separate question is whether your security team knows the test is happening. NIST SP 800-115 calls these overt and covert testing. Covert testing examines how the organisation detects and responds, which is red team territory.

Scope types

A scope says which systems are in the test and which kind of attacker the tester plays.

Mobile apps, wireless networks, hardware and OT systems are scoped the same way. NIST notes that when a test covers both internal and external networks, "the external testing usually occurs first."

How an engagement runs

NIST SP 800-115 describes four phases: planning, discovery, attack and reporting, with a loop from attack back to discovery as each foothold reveals more. PTES (the Penetration Testing Execution Standard) splits the same work into seven sections: pre-engagement interactions, intelligence gathering, threat modeling, vulnerability analysis, exploitation, post exploitation, and reporting. This guide follows the six steps a typical engagement runs through.

1. Scoping and rules of engagement

Nothing is tested in this phase. NIST: "rules are identified, management approval is finalized and documented, and testing goals are set." The output is two documents.

The scope lists every target (hostnames, IP ranges, application URLs, cloud account IDs) and every exclusion. The rules of engagement set how the test runs:

• Testing windows and time zone, and any blackout periods.
• Permitted and forbidden techniques: denial of service, social engineering, physical access, password spraying against live accounts.
• How far to go once in: proof of access only, or reading production data.
• Emergency contacts on both sides and a stop word.
• What to do when a critical finding turns up mid-test, usually an immediate call to a named contact.
• How test data, captured credentials and evidence are stored and destroyed.
• Written permission from the owner of every system, including third parties such as cloud and hosting providers whose policies require notice.

The signed scope is what makes the test lawful. Anything outside it is unauthorised access, whatever the intent.

2. Reconnaissance

The tester maps the attack surface: subdomains, exposed services, technologies and versions, employee names and email formats, leaked credentials. Passive work uses public sources (the OSINT reconnaissance guide covers these); active work uses port scanning and service enumeration. NIST groups this with vulnerability analysis, where the tester compares what was found against known weaknesses.

3. Exploitation

The tester tries to exploit what was found, to confirm it and measure its impact. A good tester stops at proof: reads one record to show access to all of them, runs whoami to show code execution. Anything that could damage data or availability is cleared with the client first.

4. Post-exploitation

Once in, the tester asks what the foothold leads to: escalating privileges, moving to other systems (see lateral movement), reaching the objectives in the scope, such as the customer database or domain admin. NIST describes this as the loop back to discovery: "Testing and analysis on multiple systems should be conducted during a penetration test to determine the level of access an adversary could gain." This phase is where a pen test earns its price over a scan, because chains of medium findings often add up to a critical one.

5. Reporting

NIST notes that reporting runs alongside the other three phases: logs are kept throughout and periodic reports go to administrators or management. Most rules of engagement also require a critical finding to be reported as soon as it is found. The final report is the deliverable you are paying for, covered in the next section.

6. Retest

After you fix the findings, the tester checks each fix. A retest is far shorter than the original test and turns "we deployed a patch" into "the tester confirmed the issue is gone." Ask for it in the original quote, along with how long after the test it stays available.

What a good report contains

A report has two readers. Management needs a short executive summary: overall risk, the few findings that matter most, and what to do first. Engineers need findings they can reproduce and fix without calling the tester.

Every finding should have:

1. Title and description. What is wrong, in one plain sentence, then the detail.
2. Affected assets. Exact hosts, URLs, endpoints, parameters.
3. Evidence. Requests and responses, command output, screenshots, with timestamps.
4. Severity. A rating with the full scoring vector so you can check it. Many firms use CVSS and state the version; some adjust for business context and say so.
5. Steps to reproduce. Numbered, complete, runnable by someone who was not on the test.
6. Remediation. A specific fix for this system, plus the general control that prevents the class of bug.
7. References. CWE, CVE, vendor advisories where they apply.

The report should also state the scope, the dates, the testers, the methodology, any limits that affected coverage (an account that did not work, a system that went down), and what was tested and found secure. A report that lists only findings leaves you unable to tell "secure" from "not tested."

Worked example: one finding, written up

Here is a finding from a grey box test of a fictional invoicing web app, written the way a good report presents it. The tester was given two customer accounts.

PT-2026-014: Any logged-in customer can read any other customer's invoices

Affected asset: GET https://app.example.com/api/v2/invoices/{invoice_id}

Description: The invoice endpoint checks that the request carries a valid session but does not check that the invoice belongs to the caller's organisation. Invoice IDs are sequential integers, so any customer can read every invoice in the system by counting. This is an insecure direct object reference (CWE-639).

Evidence: Logged in as [email protected] (organisation 1182), the tester requested an invoice belonging to organisation 2045:

GET /api/v2/invoices/48213 HTTP/2
Host: app.example.com
Authorization: Bearer eyJhbGciOi...(org-a session)
 
HTTP/2 200 OK
Content-Type: application/json
 
{"invoice_id":48213,"org_id":2045,"customer":"Org B Sdn Bhd",
 "billing_email":"[email protected]","total":"18,400.00","currency":"MYR"}

The tester read three invoices from other organisations to confirm the pattern, then stopped. No bulk download was attempted.

Severity: Medium, CVSS 3.1 base score 6.5. Vector: CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:H/I:N/A:N Reachable over the internet (AV:N), no special conditions (AC:L), needs any customer account (PR:L), no victim interaction (UI:N), full read of other customers' invoice data (C:H), no write or availability impact. The base score does not capture business impact: every customer's billing data is exposed, which the client may treat as high priority for regulatory reasons.

Steps to reproduce:

1. Log in as customer A and open any invoice. Note the ID in the request, for example 48100.
2. Repeat the request with the ID changed to a nearby value, for example 48213.
3. Observe a 200 response containing another organisation's invoice.

Remediation: In the invoice handler, load the invoice with both the ID and the caller's organisation, for example WHERE invoice_id = ? AND org_id = ?, and return 404 when no row matches. Apply the same check to every endpoint that takes an object ID; the tester saw the same ID pattern on /api/v2/payments/{id} and /api/v2/credit-notes/{id} but these were outside the agreed accounts' data and were not tested. Consider non-sequential IDs as a second layer only.

Retest: Request the same three invoices as customer A after the fix and expect 404.

A finding written this way can be fixed by an engineer who has never met the tester, and checked by an auditor who has never seen the app.

How to choose a provider

The market ranges from firms that run a scanner and reformat its output to teams that find business logic flaws no tool can. These checks separate them.

Two warning signs: a quote that does not ask scoping questions (number of hosts, applications, roles, APIs), and a sample report that is mostly scanner output with a CVSS column.

OSCP is now issued with an OSCP+ designation that expires three years after issue unless renewed (the underlying OSCP does not expire), so ask when a tester earned it. A certificate shows the tester passed an exam; the sample report shows whether the firm can turn that skill into something you can act on.

Where pen testing is a licensed activity

Malaysia and Singapore both make selling penetration testing a licensed activity. In both, the licence attaches to the provider, and in both the same regime covers managed security operations centre (SOC) monitoring.

Malaysia: Cyber Security Act 2024

The Cyber Security Act 2024 (Act 854) came into operation on 26 August 2024. Section 27(1) says no person shall "provide any cyber security service" or "advertise, or in any way hold himself out as a provider of a cyber security service, unless he holds a licence." Section 27(5) sets the penalty: "a fine not exceeding five hundred thousand ringgit or to imprisonment for a term not exceeding ten years or to both."

The Cyber Security (Licensing of Cyber Security Service Provider) Regulations 2024 (P.U. (A) 221/2024), in force the same day, name the two licensed services: managed security operation centre monitoring and penetration testing. Their definition of a penetration testing service includes simulated attacks to test an organisation's ability to detect and respond, and the use of social engineering, so red team and phishing engagements fall inside it.

Key points from the regulations and NACSA's licensing FAQ:

• The fee is RM1,000 per service for a company and RM400 per service for an individual, set per year and paid again at each renewal.
• A licence is valid for one year. Section 30 of the Act says a licensee may apply to renew at least 30 days before expiry, and the regulations treat a renewal received after expiry as a new application.
• Only the company needs the licence; its employees do not need their own.
• A subcontractor testing on behalf of a main contractor needs its own licence.
• A foreign company serving clients in Malaysia needs a licence.
• No licence is needed for services provided by a Government Entity, for a company serving only its related companies, or where the systems being tested are located outside Malaysia.
• Applications open through NACSA's portal at licence.nacsa.gov.my, which also publishes the list of licence holders.

Singapore: Cybersecurity Act 2018

Part 5 of Singapore's Cybersecurity Act 2018 licenses the same two services, listed in its Second Schedule. Section 24(1) bars anyone from engaging "in the business of providing any licensable cybersecurity service to other persons" without a licence. Section 24(2) sets the penalty: "a fine not exceeding $50,000 or to imprisonment for a term not exceeding 2 years or to both." The Act's definition of a penetration testing service also includes simulated attacks that test an organisation's ability to detect and respond.

The Cybersecurity Services Regulation Office (CSRO), set up by CSA when the licensing framework started on 11 April 2022, runs the scheme. From its licence application page and FAQ:

• Fees are S$2,500 per licence for a business entity and S$1,250 for an individual, with a separate licence for each of the two services.
• A licence is valid for five years.
• It applies to providers serving the Singapore market, including resellers, third-party vendors and overseas providers. Employees working for a licensed employer do not need their own licence, and a company serving only its related companies is exempt.
• From 16 March 2026, licensees must hold an active Cyber Trust Mark at Promoter (Tier 3) or an equivalent certification (CSRO currently recognises ISO/IEC 27001 as the equivalent), with a grace period for licensees until 31 December 2026.
• Using an unlicensed provider is not an offence for the buyer. CSRO still encourages buyers to use only licensed providers, and section 31 of the Act stops an unlicensed provider from suing to recover its fees.

How to check a licence

1. Get the provider's exact registered company name (and UEN for Singapore). Trading names often differ.
2. Search the official lists: NACSA's licence holder list at licence.nacsa.gov.my for Malaysia, and the business and individual lists on CSRO's licensed service providers page for Singapore. Our Licensed Security Provider Check searches both registers in one place and flags Malaysian licences that have expired.
3. Confirm the licence covers penetration testing specifically. A SOC monitoring licence does not cover it.
4. Check the expiry. NACSA keeps expired licences on its list, and a one-year licence can lapse between the proposal and the start date. If only an expired licence appears, ask the provider for its current licence letter.
5. Check the subcontractors too, if any testing is passed on.

A firm missing from both lists may still be operating lawfully: the registers only cover the two licensed services, for systems in Malaysia or providers serving the Singapore market, and a firm testing systems located elsewhere may need no licence at all.

The verdict

Buy a penetration test when you need proof of what an attacker can do, and buy it after you have scanning and patching in place, so the testers spend their days on what tools miss. Choose grey box for most work. Put the effort into the scope and rules of engagement, because they decide both what you learn and whether the test is lawful. Judge providers on a sample report and the named testers. Pay for the retest. And in Malaysia or Singapore, check the provider's penetration testing licence on the official register, and its expiry date, before anyone touches your systems.

Related guides

• How to Become an Ethical Hacker
• Bug Bounty Hunting: Getting Started
• The Vulnerability Management Lifecycle
• CVSS Explained
• IDOR Explained
• Social Engineering Playbook
• MITRE ATT&CK Framework Explained