What is penetration testing? A practical guide

Penetration testing is an authorized attempt to find and exploit weaknesses in a system. It helps you understand what an attacker could access, how a weakness affects the business, and which fixes deserve attention first.

A test reduces risk when its findings lead to verified fixes. A clean report means the testers did not identify reportable vulnerabilities within the work they performed. It does not prove the system was secure, even on the day of the test.

What is penetration testing?

A penetration test, often shortened to pentest, is a scoped security assessment that uses attacker techniques to evaluate applications, infrastructure, or other agreed targets. Testers investigate weaknesses, validate their impact where permitted, and document the evidence so your team can reproduce and address the findings.

For example, consider a billing application with two customer accounts. A tester checks whether one account can retrieve the other account's invoice. If the application returns the document without checking ownership, the finding establishes a specific impact: access to another customer's information. Testing should use agreed test accounts and data, with enough evidence to demonstrate the issue without unnecessarily exposing customer records. OWASP describes this vulnerability class as broken object-level authorization.

The engagement starts with written authorization and rules of engagement. Those define which systems can be tested, permitted techniques, testing windows, data-handling requirements, and who can stop the work. NIST SP 800-115 provides a reference for planning security assessments and handling their results.

Penetration testing vs. vulnerability scanning

Vulnerability scanning is useful for repeatable checks across many assets. It can identify outdated software, exposed services, and patterns associated with known weaknesses. Some scanners also perform active checks or validate particular findings.

A pentest investigates how weaknesses behave in context. Can a normal user perform an administrator's action? Can two individually limited findings combine into access to sensitive data? Answering those questions often requires authenticated sessions, an understanding of application logic, and investigation beyond a scanner's output.

Use the two together. Scanning provides repeatable coverage; a pentest adds investigation and evidence for the agreed scope. Neither guarantees that every vulnerability will be found.

What can a penetration test cover?

The target determines the skills, access, and time a test needs. A web application engagement does not automatically cover your corporate network, physical offices, or every cloud account.

Applications and APIs

Application tests examine authentication, authorization, input handling, sessions, and business workflows. For a multi-tenant SaaS product, scope should include relevant roles and more than one tenant so testers can investigate isolation between customers. APIs and connected services need explicit coverage, even when they support the same user interface.

Networks and cloud infrastructure

Network tests examine reachable services, access paths, and segmentation. External testing starts outside a defined perimeter; internal testing uses an agreed position inside it. Cloud assessments can also evaluate identity permissions, storage access, and configuration. Specify the cloud accounts and identities involved rather than assuming the word "network" covers them.

Mobile applications

A mobile assessment can cover the client, local data storage, platform interactions, and its backend APIs. Testing only the app's network traffic leaves questions about the device-side implementation unanswered. The supported platforms and available builds affect the work.

Social engineering and physical access

Social engineering exercises evaluate how people and processes respond to authorized scenarios such as phishing or help-desk impersonation. Physical testing examines agreed access controls around facilities or equipment. These require their own objectives and permissions; they are not implicit in an application pentest. Plan how to handle employee information and how the exercise will be stopped if needed.

Black-box, grey-box, and white-box testing

These terms describe the information and access supplied to the tester. They are separate from the type of system being tested.

• Black-box testing starts with limited internal information, such as a public URL or IP range. It helps assess what can be discovered from that starting position, but some of the engagement will be spent on discovery.
• Grey-box testing adds selected context, often user accounts, API documentation, or an architecture overview. It is useful for testing authenticated workflows and boundaries between roles.
• White-box testing provides extensive context, such as source code, configuration, and architecture. This helps testers investigate implementation details and paths that would be difficult to discover externally.

More information can improve efficiency and depth, but it does not create unlimited coverage. A white-box engagement still needs a defined scope and enough time to investigate the system.

How a penetration test works

Different methodologies group the work differently. A practical engagement follows the sequence below, with discovery and validation often repeated as new information appears.

1. Agree on scope and rules

Identify the applications, environments, accounts, and objectives. Document exclusions and operational limits, including whether techniques that could affect availability are permitted. Establish emergency contacts and a route for reporting urgent findings during the test. Confirm authorization for third-party systems separately.

2. Map the target

Testers gather information, identify reachable services and application functions, and understand how accounts and systems relate to each other. Discovery can include both public information and active interaction with the target.

3. Investigate and validate weaknesses

Testers examine candidate issues and attempt to demonstrate impact within the agreed limits. Where authorized, they may investigate whether initial access enables privilege escalation or access to another system. A test should stop at the agreed evidence threshold; it need not establish persistence or copy sensitive datasets to demonstrate a serious finding.

4. Report evidence and limitations

The report should connect each finding to the affected component, required access, evidence, impact, and recommended remediation. It should also explain what was tested and what could not be tested. A severity score is useful context, but the business impact and prerequisites matter when deciding what to fix first.

Agree on how urgent issues will be reported before the final document arrives. Human-led testing can include immediate escalation and shared findings throughout the engagement.

5. Fix and retest

Assign owners, make the changes, and repeat the relevant test against the fixed environment. Track unresolved issues and accepted risks explicitly. Closing a ticket records a workflow decision; a retest provides evidence about whether the demonstrated weakness remains exploitable.

A useful report gives engineering enough detail to act and leadership enough context to prioritize. Agree on those deliverables before the engagement starts.

Who should conduct the test?

Organizations use internal specialists, external consultancies, automated testing platforms, or a combination. Choose based on the target, the depth required, and any independence requirements attached to the assessment.

Ask who will perform the work, what experience they have with your stack, and how they validate findings. Review a redacted sample report and agree on retesting and urgent escalation. Certifications such as OSCP, CEH, and GPEN can contribute to evaluating a tester, but their assessment formats differ. A certification alone does not establish suitability for your application.

Cost depends on scope, complexity, the access provided, and the work included after testing. A quote should state the environments, roles, and workflows covered, any exclusions, and whether retesting is included. Comparing prices without comparing those details can hide a much narrower engagement.

How penetration testing helps protect the business

A demonstrated finding gives engineering a concrete problem to fix and helps security explain its impact. Testing can reveal gaps in access controls, validate isolation between systems, and provide evidence for customer security reviews. Our guide to the benefits of penetration testing covers these outcomes in more detail.

It can also help evaluate detection and response when those are explicit objectives. For example, the team can check whether an agreed test action generated the expected alert and whether it reached the right responder. A standard application pentest does not automatically exercise the entire incident-response program.

What about compliance?

Pentest evidence can support an assessment, but requirements vary. PCI DSS contains specific penetration-testing requirements; check the applicable standard for scope, frequency, independence, and retesting.

SOC 2 evaluates controls against the AICPA Trust Services Criteria. Discuss the evidence needed for your system and controls with your auditor. A pentest report alone does not establish SOC 2 compliance.

The HHS summary of the HIPAA Security Rule describes risk analysis and periodic technical and non-technical evaluation. A pentest can contribute evidence, but it is only one part of those obligations.

How often should you run a penetration test?

Start with applicable contractual and assessment requirements, then account for changes to the system. New authentication flows, tenant-isolation changes, infrastructure migrations, and significant integrations can justify focused testing before the next scheduled engagement.

A completed test remains useful evidence about the work performed. It does not automatically cover subsequent changes.

Combine periodic assessments with checks suited to the development process: code review, dependency analysis, scanning, and targeted adversarial testing. Match each check to the question it can answer. For a closer comparison, read continuous testing vs. annual pentests.

Where automated testing fits

Automated and AI-assisted pentesting can make repeated testing more practical. Its value depends on the coverage, credentials, scope controls, and validation it provides. Running more frequently does not prove that a tool has tested every path or replaced the judgment of an experienced tester.

Parameter's AI pentesting supports testing applications and APIs, investigating access-control and business-logic issues, and producing validated findings with reproduction steps. Teams can rerun tests after fixes and use the results alongside specialist assessments. Human expertise remains important for novel scenarios and work outside the platform's coverage.

Frequently asked questions

Is penetration testing the same as ethical hacking?

Ethical hacking is a broader term for authorized security research and testing. A penetration test is a defined engagement with agreed targets, objectives, limits, and deliverables.

Does a clean pentest report mean there are no vulnerabilities?

No. It means no reportable vulnerabilities were identified within the work performed. Time, access, methodology, and scope limit any test. Read the coverage and limitations alongside the findings.

Should a pentest run in production or staging?

Choose an environment that answers the test's objectives within acceptable operational limits. Staging can reduce disruption risk, but differences in identity settings, integrations, or infrastructure can make its results less representative of production. Document those differences when interpreting the report.

Will the test disrupt our systems?

Active testing can affect systems. Agree on permitted techniques, test data, timing, monitoring, and stop conditions before work begins. Availability testing or other disruptive activity should be explicitly scoped rather than assumed.

What should we do before booking a pentest?

List the systems and critical workflows you want assessed, identify who can authorize access, and prepare the relevant accounts and documentation. Agree on how findings will reach engineering and reserve time for remediation and retesting. Those decisions make the report easier to turn into fixes.