CYBERCILE Schedule a Pen-Test

CYBERCILE SECURITY LAB

Your Customer Asked for a Penetration Test. What Do You Actually Need?

Before you start collecting quotes, determine what they are asking you to prove, which systems need to be tested, and what evidence they expect when the test is complete.

A practical buyer’s guide from an ethical hacker.

Take the Security Assurance AssessmentTalk to a Security Expert

5-minute assessment • No sensitive information required

On this page

First, find out why they're asking.

A request for a penetration test usually starts with something else.

An enterprise customer may be completing vendor due diligence.

A banking partner may need security evidence before approving or continuing a relationship.

Procurement may require independent security testing before a contract can move forward.

An auditor may need evidence that specific systems have been assessed.

Or your team may be preparing to launch a new application, API, or critical feature.

Those situations can sound similar, but they do not always require the same testing scope or deliverables.

Before requesting quotes, answer three questions:

  1. Who is requesting the test?
  2. What systems or products are they concerned about?
  3. What evidence do they expect when testing is complete?

Do not begin with "How much does a pentest cost?"

Begin with: "What are we being asked to prove?"

What exactly needs to be tested?

"Penetration test" can describe very different engagements.

Web Application

Use when the application itself is in scope.

Testing may include:

  • Authentication
  • Authorization
  • Session management
  • Input handling
  • Business logic
  • Privilege boundaries
  • Sensitive data exposure
  • Application-specific attack paths

API

Use when APIs expose data, transactions, account functions, integrations, or business-critical workflows.

Testing may include:

  • Object-level authorization
  • Function-level authorization
  • Authentication
  • Token handling
  • Rate limiting
  • Input manipulation
  • Business logic abuse
  • Data exposure
  • Privilege escalation

External Infrastructure

Use when internet-facing infrastructure is part of the requested assessment.

Testing may include:

  • Exposed services
  • Configuration weaknesses
  • Authentication surfaces
  • Attack paths
  • Privilege escalation opportunities
  • Internet-facing vulnerabilities

Full-Stack Testing

Use when risk crosses application, API, infrastructure, identity, and business workflows.

For many modern financial technology environments, testing only the visible web interface can leave important attack paths outside the scope.

The correct scope should follow the system and the risk, not simply the easiest asset to test.

Does an automated vulnerability scan count as a penetration test?

Usually, no.

A vulnerability scanner is useful for identifying known weaknesses, exposed software, configuration issues, and other detectable conditions at scale.

A penetration test asks a different question:

Can a human tester use weaknesses, application behavior, trust relationships, authorization failures, or business logic to create a meaningful attack path?

That distinction matters.

A scanner might identify an outdated component.

A penetration tester may determine whether that weakness can actually be exploited in your environment.

A scanner may report that an endpoint exists.

A tester may discover that changing an object identifier exposes another customer's financial information.

A scanner may confirm that MFA is enabled.

A tester may investigate whether account recovery, session behavior, or another workflow bypasses the intended protection.

Vulnerability scan

  • Find known conditions
  • Automated at scale
  • Broad coverage
  • Useful for continuous hygiene

Penetration test

  • Test exploitability
  • Human-led adversarial reasoning
  • Explore attack paths
  • Challenge business logic and controls

Scanning tells you what may be vulnerable.

Penetration testing investigates what an attacker may actually be able to do.

What should you know before requesting quotes?

  • The application or systems in scope
  • Production, staging, or another environment
  • Web application URLs
  • API documentation or endpoints
  • User roles and permission levels
  • Authentication methods
  • Cloud or infrastructure scope
  • Important integrations
  • Sensitive or high-value workflows
  • Known restrictions
  • Desired testing window
  • Required completion date
  • Customer, bank, audit, or procurement deadline
  • Required report format or evidence
  • Whether remediation retesting is required

You do not need every technical detail before speaking with a testing company.

But the more clearly the environment and objective are defined, the more meaningful the scope and quote will be.

How do you know you're buying a real penetration test?

Do not evaluate a penetration testing company only by certifications, price, or the number of vulnerabilities they promise to find.

Ask how the testing is actually performed.

Questions worth asking

  1. How much of the engagement is manually tested?
  2. Who will perform the testing?
  3. Will we speak with the tester or only an account manager?
  4. How do you test application and API business logic?
  5. How do you validate automated findings?
  6. Can we review a sanitized sample report?
  7. How do you determine finding severity and business impact?
  8. Does the report explain reproduction and remediation?
  9. Is remediation retesting included?
  10. What evidence do we receive after a finding is successfully remediated?

A polished PDF does not tell you how deeply your systems were tested.

Methodology does.

What should a useful penetration test report give you?

A penetration test report should help more than the security team.

Engineering needs enough information to reproduce and remediate findings.

Security needs exploitability and attack-path context.

Leadership needs to understand material risk.

Compliance, customers, banking partners, or auditors may need evidence that independent testing occurred.

  • Executive summary
  • Scope and methodology
  • Systems tested
  • Testing dates
  • Validated findings
  • Severity and business impact
  • Attack or exploitation path
  • Supporting evidence
  • Reproduction details
  • Remediation guidance
  • Testing limitations
  • Residual risk
  • Retest status when applicable

A report should help your organization answer three questions:

  1. What can be exploited?
  2. What needs to change?
  3. How will we prove it was fixed?

What happens when vulnerabilities are found?

  1. FIND

    Identify and validate exploitable security weaknesses.

  2. PRIORITIZE

    Determine what matters based on exploitability, attack path, affected systems, and business impact.

  3. REMEDIATE

    Engineering or system owners implement corrective action.

  4. VERIFY

    Retest the original condition and challenge the remediation where appropriate.

  5. PROVE

    Retain evidence showing what was tested, what changed, and the resulting validation status.

Finding a vulnerability is only the beginning.

Should vulnerabilities be retested after they're fixed?

Yes, when the finding matters.

A closed ticket confirms that remediation work was performed.

It does not independently demonstrate that the original attack path no longer works.

Verification should determine whether:

  • The original vulnerability can still be reproduced.
  • The remediation addresses the underlying security condition.
  • Reasonable bypasses or alternate paths remain.
  • The change introduced another weakness.
  • Evidence supports the final result.

CLOSED ≠ VERIFIED

CyberCile uses explicit validation outcomes so remediation status is not ambiguous:

  • Verified
  • Partially Fixed
  • Not Fixed
  • Unable to Verify

Explore Independent Remediation Validation for a separate check of remediation.

Planned reading: How Do You Know a Vulnerability Was Actually Fixed?

What should you give the customer, bank, or auditor afterward?

Do not assume every requesting organization needs your complete technical penetration test report.

Depending on the request and sensitivity of the findings, evidence may include:

  • An executive summary
  • Testing scope
  • Assessment dates
  • Testing methodology
  • Independent testing confirmation
  • Finding status
  • Remediation status
  • Retest or verification results
  • Supporting closure evidence
  • Residual risk information

The requesting organization should tell you what evidence it requires.

Your goal is to maintain enough defensible security evidence that producing it does not become an emergency every time a customer asks.

Security evidence should be built during the work, not reconstructed six months later.

Not sure whether a pentest is the only thing you need?

A penetration test may be exactly the right next step.

But if you're preparing for a bank review, enterprise customer, audit, major launch, or broader security requirement, the real gap may involve testing, remediation, verification, evidence, or several of them together.

Take the CyberCile Security Assurance Assessment to identify where your current process is strongest and where additional assurance may be needed.

Take the 5-Minute Assessment

No sensitive information required.

If you need testing, remediation, and verification across a broader effort, explore 90-Day Financial Systems Assurance.

When a penetration test is the right next step

If you already know which application, API, or infrastructure needs independent adversarial testing, CyberCile can help define the scope and execute the assessment.

  • Human-led testing
  • Attack-path focused findings
  • Actionable remediation evidence
Discuss Your PentestExplore Penetration Testing →

Frequently Asked Questions

How long does a penetration test take?

Timing depends on the number of systems, user roles, integrations, testing depth, and access readiness. Ask for separate dates for scoping, hands-on testing, report delivery, remediation, and retesting. Confirm that the schedule meets the requesting organization’s deadline.

How much does a penetration test cost?

Cost depends on scope and the time needed for meaningful manual testing. Compare proposals using the same systems, roles, methodology, deliverables, and retest allowance. A low quote may cover a narrower scope. Ask what is excluded before comparing totals.

Do we need a penetration test every year?

There is no single schedule for every organization. Contracts, applicable requirements, system changes, and organizational risk determine the cadence. Confirm the requester’s expectations and consider additional testing after significant changes to authentication, APIs, or critical workflows.

Does a vulnerability scan count as a penetration test?

Usually, no. Scanning identifies detectable conditions at scale. A human-led penetration test investigates exploitability, authorization, business logic, and attack paths within an agreed scope. Ask the requesting organization what methodology and evidence it will accept.

Should APIs be included in a penetration test?

Include APIs when they handle relevant data, transactions, integrations, or application functions. A web-interface-only scope can miss direct API access and authorization weaknesses. Identify the endpoints, versions, roles, and critical workflows during scoping.

Can a pentest be performed in production?

It can, when explicitly authorized and carefully scoped. Agree on testing windows, prohibited actions, monitoring, stop conditions, recovery arrangements, and emergency contacts. Staging may be more suitable for disruptive tests, but differences from production must be documented as limitations.

Do vulnerabilities need to be retested?

Retest meaningful findings to determine whether the original condition is resolved and reasonable bypasses remain. A closed engineering ticket is not independent verification. Agree on the retest window, coverage, cost, and evidence before testing begins.

Can we share our penetration test report with customers?

Confirm what the customer needs and review confidentiality obligations before sharing. A scoped executive summary, testing confirmation, or retest statement may be sufficient. Share sensitive technical details only with authorized recipients using an appropriate secure channel.

What information does a pentest company need to provide a quote?

Provide the objective, systems and environment, application URLs, API scope, roles, authentication methods, integrations, restrictions, deadline, and expected deliverables. Clarify whether remediation retesting is included. Detailed credentials and sensitive technical materials should use an agreed secure process.

Do we need a penetration test before a bank or enterprise security review?

It depends on the relationship, requested evidence, system exposure, and applicable contractual or regulatory requirements. Ask the reviewer to confirm scope, independence, acceptable testing dates, methodology, and remediation expectations. A penetration test may address one part of a broader review.

About the author

Cecile Mengue
CyberCile founder and ethical hacker.

Cecile brings an offensive-security perspective to testing, remediation, and the evidence organizations need to understand their security.