What is a penetration test?

A tester works through the stages an attacker would, inside rules you agree in writing before anything starts.

1. Agree the scope. You and the tester write down which systems are in play, which are off limits, when testing may run and who to call if something looks wrong.
2. Map the surface. The tester finds the hosts, routes, roles and features in scope and uses the product as each kind of user.
3. Work the leads. Anything that looks weak is tested by hand: a request replayed as another user, a step skipped in a checkout, a token reused where it should fail.
4. Prove the reach. A lead becomes a finding only when a working exploit shows what it reaches, such as another customer's records or an admin action.
5. Report and retest. Each finding is written up with its proof and a fix. Once the fix is live, the tester runs the exploit again to check that it holds.

Tools help at every stage, above all with mapping a large surface. The judgement of what to chase, and what counts as a real finding, belongs to the tester.

A penetration test covers what the scope names, and nothing else. A scope can be one web application, an API, a mobile app and the backend it calls, a cloud account or an AI feature inside a product.

Out of scope means out of bounds. Systems you do not own, third-party services you rely on and anything you list as off limits are left alone, even when a path seems to lead there. A good scope also says how testing behaves on live systems: inside agreed windows, with a named contact on your side and no destructive actions.

Because a test covers a defined scope on defined dates, a clean result has a precise meaning: the paths the tester tried did not work on the dates tested. It is evidence about that scope, not a promise that nothing else is there.

You get a report your engineers can act on and your leadership can read. For every finding, a useful report holds:

• proof of exploit: the request and response, or the exact steps, so your team can reproduce it
• the business risk in plain language: what an attacker could reach, and why it matters
• a severity rating, so fixes can be ranked
• a fix written for the engineer who will make the change

Alongside the findings, expect a summary for leadership that says what to fix first. To see how one finding reads from start to finish, open a sample finding.

Each one answers a different question.

• A vulnerability scan asks what might be wrong. An automated tool checks many hosts for known flaws and returns a list of possible issues to verify. See how a scan differs from a penetration test.
• An audit asks whether your controls match a written standard. It reviews policies, settings and evidence, and usually does not try to break in.
• A red team assessment asks whether your defenders would notice an attack. It pursues one agreed objective and records which steps were seen. See red team assessment.
• A penetration test asks what an attacker could actually reach in the systems you name, and proves it.

Any team whose product holds customer data, moves money or grants access that others rely on. The usual moments to book one:

• before a launch, so a tester finds the weak points before an attacker does
• after a large change, such as a new sign-in flow, a new integration, a new tenant model or a move to new hosting
• when a customer or partner asks how your product has been tested
• after fixing an earlier test's findings, to confirm the fixes hold

If your product changes with every release, one test ages quickly. Some teams test in rounds instead: continuous penetration testing runs a full test each quarter.

GreySurface testing is human-led and AI-assisted. A tester leads every test and works each lead by hand, AI speeds up recon, triage and reporting, and a person reviews every finding before it reaches you.

Every finding comes with proof of exploit, the business risk and a fix, rated Critical, High, Medium or Low. Every test includes an executive briefing, and a one-off test includes one retest within 30 days of the report.

Every step is on how a GreySurface test runs, and each kind of test is on penetration test types.