Offensive Security & Penetration Testing

We attack your applications, networks and people the way a determined adversary would, then show you exactly how to fix what we find.

Get Started

Who this is for

A penetration test is most valuable when it answers a specific question about your exposure. These are the situations where that question usually arises.

  • A company preparing for SOC 2, ISO/IEC 27001, HITRUST or PCI DSS whose auditor expects an independent penetration test.
  • A product team about to launch a new web application, mobile app or API and wanting it tested before customers rely on it.
  • An enterprise customer's security review has asked for a recent third-party test report.
  • A security leader who wants to know whether detection and response would actually catch an intrusion.
  • An acquirer or investor wanting technical proof of a target's security claims.

What's included

Each test is scoped to specific assets, agreed in writing and run under signed rules of engagement. Testing combines industry-standard tooling with manual analysis, because automated scanners miss logic flaws and chained attacks.

  • Web application and API testing

    We test authentication, session handling, access control, input handling and business logic against the OWASP Top 10 and the OWASP Web Security Testing Guide.

  • Mobile application testing

    We examine iOS and Android apps for insecure storage, weak transport security, reverse-engineering exposure and backend API flaws, following the OWASP mobile standards.

  • External network testing

    We map your internet-facing attack surface and test exposed services, misconfigurations and weak authentication.

  • Internal network testing

    We start from the position of a compromised workstation or a malicious insider and attempt privilege escalation and lateral movement.

  • Cloud configuration testing

    We probe identity, storage, network and workload settings for paths to sensitive data.

  • Social engineering

    We run phishing, phone-based pretexting and, where authorized, physical access tests to measure how staff respond.

  • Wireless and segmentation testing

    We verify that network segments hold, including cardholder data boundaries for PCI DSS.

  • Retesting

    We verify that your fixes work and update the report to show which findings are closed.

How an engagement works

Most tests take 1 to 3 weeks of active testing. Scheduling, reporting and retesting extend the full engagement.

  1. Scoping and rules of engagement

    We agree targets, testing windows, test accounts, permitted techniques, emergency contacts and written authorization before any testing starts.

    Typically 1 week

  2. Reconnaissance and mapping

    We enumerate your attack surface, technologies and entry points to plan the test.

    Typically 2 to 3 days

  3. Testing and exploitation

    Our testers probe for vulnerabilities, confirm them by exploitation within agreed limits, and chain weaknesses to show real impact. We tell you immediately about any critical finding.

    Typically 1 to 3 weeks

  4. Reporting and readout

    We deliver a written report and walk your engineers and leadership through it.

    Typically 1 week

  5. Retest

    We re-verify remediated findings and issue an updated report.

    Typically 1 to 2 weeks, after your fixes

Testing can be black box with no prior knowledge, grey box with user-level credentials, or white box with documentation and source access. Grey box testing is the most common choice because it finds more issues in the time available.

Social engineering tests follow the same phases, with additional safeguards: a named sponsor approves the pretexts, results are reported by group and not by individual, and no one is disciplined on the basis of the test.

What you receive

Reports are written for two readers: the engineer who has to fix the issue and the executive who has to decide what it is worth.

  • An executive summary that states overall risk and the business impact of the most serious findings.
  • A technical report with each finding's description, evidence, reproduction steps, CVSS-based severity and remediation guidance.
  • An attack narrative showing how individual weaknesses chain together into compromise.
  • A prioritized remediation list your engineers can load straight into their backlog.
  • A retest report confirming which findings are closed.
  • A summary letter suitable for sharing with customers and auditors, describing scope, dates and methodology.

Frameworks and standards

We test against published methods, which keeps results repeatable and defensible to an auditor.

  • OWASP Top 10, WSTG and ASVS

    The basis for web application and API testing.

  • OWASP MASVS and MASTG

    The basis for mobile application testing.

  • OWASP Top 10 for LLM Applications

    Used when testing applications that embed large language models.

  • NIST SP 800-115

    Technical guide to information security testing and assessment.

  • PTES

    The Penetration Testing Execution Standard, which structures our phases.

  • MITRE ATT&CK

    Adversary techniques we map our activity and findings to.

  • PCI DSS v4.0.1

    Requirement 11 penetration testing, including segmentation testing.

  • CVSS

    The scoring system used to rate severity.

Why Velero

The value of a penetration test depends on who runs it and how it is reported. Our method addresses both.

  • Manual, senior-led testing

    Experienced testers design and run each engagement, and we do not hand you scanner output with a cover page.

  • Independent of your build and your audit

    We do not write your code or issue your audit reports, so our findings carry no conflict of interest and we work alongside your assessor.

  • Plain-English reporting, with remediation support

    Every finding explains the risk and the fix, and we answer your engineers' questions during remediation and retest.

FAQCommon questions

What is the difference between a vulnerability scan and a penetration test?

A vulnerability scan uses automated tools to list known weaknesses. A penetration test adds manual analysis to confirm which ones are exploitable, find flaws that scanners cannot detect, and show what an attacker could actually reach.

Will testing disrupt our production systems?

We design tests to avoid disruption. We agree testing windows, rate limits and prohibited actions in advance, and we stop and contact you if a test risks affecting availability. Where possible, we recommend testing a production-equivalent environment.

How often should we run a penetration test?

At least annually, and after major changes to architecture, infrastructure or application functionality. PCI DSS requires testing at least once every 12 months and after significant changes, and many SOC 2 and ISO/IEC 27001 programs expect the same cadence.

Do you test applications that use AI or large language models?

Yes. We test the surrounding application and its APIs, and we assess LLM-specific risks such as prompt injection and insecure output handling against the OWASP Top 10 for LLM Applications.

Do we get a retest after we fix the findings?

Yes. Retesting is part of how we scope engagements. We re-verify each remediated finding and update the report so you can show customers and auditors that issues are closed.

Related servicesExplore related services

Let's talkReady to secure your business?

Tell us what you're working toward and we'll get back to you within one business day.

Schedule a call