What penetration testing covers, how it differs from vulnerability scanning, and how to plan an engagement—from choosing the scope and provider to fixing findings and verifying the results.
Last updated October 14, 2026
Penetration testing is an authorized security assessment that investigates how weaknesses in applications, networks, or other systems could be exploited. Testers work within agreed boundaries to identify vulnerabilities, demonstrate their impact, and document what needs to change.
A pentest can help answer specific questions: Could someone reach sensitive data from the internet? Could a compromised employee account gain additional privileges? Do the controls separating customers actually prevent unauthorized access?
The results describe what testers assessed and demonstrated under the conditions of the engagement. They cannot establish that every vulnerability has been found or that the environment will remain secure after changes. NIST’s guide to security testing and assessment provides a foundation for planning and conducting this work.
Vulnerability scanning uses automated checks to identify potential weaknesses across systems. It supports repeatable coverage and helps teams find issues such as vulnerable software and insecure configurations.
Penetration testing adds investigation into how a system behaves, whether a weakness is exploitable, and what access it could provide. Testers use tools alongside manual techniques to examine permissions, workflows, and combinations of weaknesses.
| Question | Vulnerability scanning | Penetration testing |
|---|---|---|
| What does it examine? | Conditions covered by automated checks | Security weaknesses and their practical impact within an agreed scope |
| How does it work? | Repeatable automated tests | Manual investigation supported by tools |
| Where is it useful? | Broad, recurring checks | Deeper assessment of selected systems and attack scenarios |
| What does it produce? | Potential vulnerabilities requiring review and prioritization | Findings supported by evidence and remediation guidance |
OWASP’s Web Security Testing Guide recommends combining testing techniques because automated checks alone cannot fully assess application-specific behavior.
Suppose an expense application requires a manager to approve reimbursements. A tester might examine whether an employee can change the amount after approval or approve their own submission through another interface. Assessing that behavior requires understanding the intended approval process.
Choose the testing discipline that matches the systems and access you want assessed.
| Test type | Typical focus |
|---|---|
| Web application | Application functions, permissions, sessions, and business workflows |
| API | Authentication, authorization, exposed data, and permitted operations |
| Mobile application | Mobile client behavior, local data handling, and connections to backend services |
| External network | Infrastructure and services reachable from the internet |
| Internal network | Access, privilege escalation, and movement between internal systems |
| Wireless | Wireless access controls, configuration, and network separation |
| Social engineering | How people and processes respond to agreed deception scenarios |
These categories can overlap. A mobile application assessment may also need API testing, while an application test may require several user roles.
Red teaming typically emphasizes an adversary’s objectives and the organization’s ability to detect and respond across a broader scenario. Confirm whether that is the outcome you need or whether a focused pentest would answer your questions. Explore Halo Security’s penetration testing services for the available assessment types.
Compliance can shape the scope, timing, and documentation of a pentest. Some standards prescribe testing requirements; others ask organizations to select and evaluate controls based on risk. A pentest report provides evidence for that work, but does not establish compliance on its own.
SOC 2 evaluates controls against the AICPA Trust Services Criteria. The criteria do not impose a universal annual pentest requirement. Penetration testing is one way to evaluate controls, and the points of focus for CC4.1 identify it as a possible assessment activity.
Plan testing around your risks, documented controls, and commitments to customers. Discuss the scope, frequency, and evidence with your auditor before the engagement. If your control promises an annual pentest, retain evidence that it happened and that findings were reviewed and addressed.
Where applicable, PCI DSS v4.0.1 Requirement 11.4 calls for internal and external penetration testing at least every 12 months and after significant infrastructure or application changes. The methodology must cover the cardholder data environment (CDE) perimeter and critical systems, including application and network layers. Testers must be qualified and organizationally independent.
If segmentation isolates the CDE, test those controls at least annually and after changes; service providers must do so at least every six months and after changes. Correct exploitable findings according to risk and repeat testing to verify the fixes. Quarterly ASV vulnerability scans are a separate requirement and do not replace a pentest.
Confirm which requirements apply to your environment and validation method with your assessor or acquiring bank. See PCI DSS v4.0.1 in the PCI Security Standards Council document library.
ISO/IEC 27001 defines requirements for an information security management system built around risk assessment and treatment. Pentesting can support that program by evaluating selected technical controls and informing remediation. Define its scope and cadence around the risks and controls in your management system.
Before booking a compliance-driven test, agree on the systems and controls covered, tester qualifications, testing dates, report contents, and remediation and retesting records. Leave time to fix and verify findings before the assessment deadline. Our compliance penetration testing services can help you plan the engagement.
Start with the decision the test should support. You might need evidence for a customer review, an assessment before launch, or a better understanding of what an attacker could reach.
Then identify the systems, interfaces, user roles, and environments involved. A product name alone leaves room for different interpretations of coverage.
Your written scope should establish:
Within a fixed budget, adding systems can reduce the attention available for each one. Ask the provider to explain that tradeoff and identify what would remain untested.
Staging also needs scrutiny: differences in configuration, authentication, or integrations can limit what its results tell you about production.
For a detailed walkthrough, read Choosing the right scope for your next pentest.
Preparation helps testers spend their time investigating security behavior.
Use asset discovery and vulnerability scanning to understand your environment and address straightforward issues before the engagement. Share unresolved findings so testers can consider them in their investigation.
Walk the team through sensitive data flows, unusual workflows, and legacy applications. Explain where you have doubts about the controls. A custom process that seems obvious to employees may be difficult for an outside tester to understand without context.
These principles also underpin our practical guide to planning a penetration test: resolve what routine checks can identify, direct attention toward business risk, and communicate openly with the testing team.
Before work begins, establish written authorization and rules of engagement. Agree on testing windows, prohibited activities, emergency contacts, stop procedures, and how testing data will be handled. NIST’s assessment guidance covers these planning and coordination requirements.
An engagement should move through a documented process:
These activities can overlap. A finding may lead to further discovery, and an urgent issue may need to be reported while testing continues. NIST describes this iterative testing process.
Tester expertise and the effort allocated to the engagement are major cost drivers. The scope determines how much work is needed: a small application and a product with multiple interfaces and permission levels present different testing demands.
A useful budget conversation starts with priorities. Identify the data, services, and workflows where a compromise would cause the most harm, then discuss the effort needed to assess them.
Avoid using price alone to judge quality. Ask what the proposed allocation allows the testers to investigate and where it limits coverage. Our pentest planning guide discusses balancing expertise, effort, and business priorities.
Ask for evidence behind the proposal. Find out who will perform the work, what comparable environments they have tested, and how they will investigate your specific risks.
Request a sample report and review it with someone responsible for remediation. Confirm that your team can discuss findings with the testers.
Before signing, clarify:
Retesting terms deserve a direct conversation. Ask about eligible findings, request deadlines, included rounds, and updated documentation.
Use our 12 Questions to Ask a Penetration Testing Company Before You Hire Them to compare providers and record unresolved questions.
A useful report supports both business decisions and technical remediation. Look for:
These elements align with OWASP’s reporting guidance.
Read the limitations alongside the findings. An untested feature and a tested feature with no identified issue represent different levels of evidence.
Assign each finding to someone who can address it. Use the demonstrated impact and business context to set priorities, then track remediation through verification. This connects penetration testing to the validation and remediation work described in our CTEM guide.
A practical tracking record should include an owner, target date, proposed fix, and verification status. Record unresolved issues and any interim controls so they remain visible.
Retesting should document whether the original issue is resolved, remains open, or is only partially addressed. An updated report gives future readers a clearer account of what changed. OWASP’s reporting guidance includes recording the status of previously identified vulnerabilities.
External attack surface management continuously discovers and assesses internet-facing assets. It helps maintain visibility as systems appear, change, or are retired.
Penetration testing provides deeper investigation of selected systems and scenarios. Findings from ongoing discovery and scanning can help identify where that investigation would be useful.
Continuous threat exposure management connects scoping, discovery, prioritization, validation, and remediation into a recurring program. Pentesting supports validation by examining whether exposures provide a usable attack path.
For example, discovery might reveal an unfamiliar application. Once ownership and authorization are established, testing could assess its access controls. The resulting findings would then inform remediation and verification.
Set a recurring schedule based on risk and applicable requirements, and reconsider coverage after substantial changes. New authentication flows, integrations, or permission models can introduce behavior that the previous assessment did not examine. OWASP recommends integrating security testing throughout the development lifecycle.
Duration depends on the agreed scope and effort. Ask for separate dates for testing, report delivery, and follow-up. Also confirm how access delays or scope changes affect that schedule when evaluating a provider.
No. It records the outcome of a particular assessment. Review its coverage, access, and limitations before drawing conclusions. A pentest report is a record of testing at a point in time, as OWASP’s reporting guidance explains.
Halo Security provides manual penetration testing with direct access to US-based testers, practical remediation guidance, and included retesting.
Bring us your testing objective, a brief description of your environment, and your deadline. We’ll help define an engagement your team can use to find weaknesses and verify fixes.