Most companies that test their apps regularly buy pen testing on a yearly contract, and plenty renew with the same vendor for years. A one-off, also called a one-time pentest, is the other way to buy it: a single test with no commitment beyond it. You pay for the test you need today, get the report, and leave next year’s decision for next year. The sections below cover when that freedom is worth having and what it gives up, with a side-by-side look at one-off and multi-year engagements.
Quick Answers
What is a one-off pen test?
A single penetration test bought without an ongoing contract. The scope can be one app or several assets, such as web apps, APIs, and cloud accounts, but it’s tested once and the engagement ends with the report.
Who buys one?
Companies with a specific need right now: a large customer asking for a report, the sale or purchase of a company, an audit, or a first test. It also suits teams that can’t yet say whether they’ll need testing next year.
Is a one-off cheaper?
No, not per test. Longer engagements usually come out cheaper per test, because vendors give better rates for a multi-year commitment.
How long does it take?
Testing a single app can take as little as five business days once the testers have access. Larger scopes take longer, usually 10 to 15 business days. If you add remediation testing and support, a window of about 90 days opens after the report: the testers help while you fix the issues, then re-check each fix.
What a One-Off Engagement Is
What makes a test a one-off is the contract around it. You and the provider agree on the scope before anything starts. For a small company that might be one web app and a couple of user roles (an admin and a regular customer, for example). A larger company might put several apps, a public API, and a cloud environment into the same engagement. Testers work through it, deliver a report that ranks each finding by severity with steps to fix it, and the engagement closes. Nothing renews, and nothing obliges you to come back.
The testing itself can be identical to what you’d get on a longer contract. The bulk of what you pay for is manual work by experienced testers. Automated tools handle some of the groundwork, but the core of the test is a person using your app the way a customer would, then trying what a customer shouldn’t be able to do, such as opening someone else’s invoices by changing a number in the web address.
Pricing is where the difference shows. Most vendors would rather sign clients for several years, and their rates reflect it: a multi-year commitment usually lowers the price per test, while a one-time project may be quoted higher or turned down altogether. During scoping, ask how the price would change with a longer commitment, even if you don’t plan to take it.
When a One-Time Test Makes Sense
Most one-offs are bought for a specific purpose, and the test covers that purpose and nothing beyond it.
A big contract is the most common reason. A larger customer’s security team sends a vendor questionnaire, and somewhere in it sits a line like “Has a third party penetration-tested your application in the last 12 months? Attach the report.” For a company that doesn’t sell to many enterprises, that request might come up once. One test produces the report and the deal moves forward. Day to day, the team can rely on an automated scanner such as a DAST tool (dynamic application security testing, software that probes a running app for known weaknesses) to catch common issues between deals.
Selling or buying a company is another. Acquirers review security during due diligence, and a recent report on the target’s apps gives both sides a factual starting point. After closing, testing becomes the new owner’s decision, so a long contract signed beforehand rarely makes sense.
Audits are a third, with more rules attached. SOC 2 doesn’t strictly require a pen test, but auditors commonly look for one. A Type 1 report checks your controls as of a single date, so one test shortly before that date fits it well. Type 2 covers an observation period of several months; a single test still counts if it lands inside that window, though many auditors see tests spread across the period as stronger evidence. If you handle card data directly, PCI DSS (the card-payment standard) requires a test at least once every 12 months and again after any significant change. Keep in mind that an audit repeats every year, and so does the test it calls for. The report is evidence, too, and the auditor decides what it proves. A pen test on its own doesn’t make you SOC 2 compliant.
Then there’s plain uncertainty. Some companies don’t know whether they’ll need a test next year at all. The product might pivot, the enterprise customer might not renew, budgets move. A one-off handles today’s need without betting on any of that.
One-Off vs. a Multi-Year Engagement
For most companies, testing turns periodic sooner or later. The real choice is whether to sign for that rhythm up front or buy a one-time test whenever the need comes up.
Flexibility is the strongest argument for buying one at a time. If the testers disappoint you, or you find a vendor you like better, you don’t renew. There’s no contract to exit and no unused tests left over. Some companies change vendors every year, and a one-off makes that easy.
The trade-offs show up in year two. A new vendor means a new contract to negotiate and review, and a new team that has to learn your app from scratch: how it’s built, what earlier reports found, which fixes went in and which risks you decided to accept. Each provider writes reports its own way, so findings are hard to compare from one year to the next. Most providers also skip the dashboard on a one-off (the online portal where findings and fixes are tracked live), delivering a report and a call instead. And you’ll usually pay more per test.
A multi-year engagement turns most of that around. The same testers come back already knowing the app, the scope shifts as the product does (a new API this year, a mobile app next), and every finding and fix sits in one history. The two common formats are continuous testing, which pairs scheduled manual tests with automated scanning in between, and PTaaS (Penetration Testing as a Service), which prepays a set number of tests across the year. The table groups them together against a one-off:
| One-off pen test | Multi-year engagement (PTaaS or continuous) | |
| Commitment | One test, nothing after | A yearly or multi-year contract |
| Price per test | Usually higher, and some vendors decline small jobs | Usually lower in exchange for the commitment |
| Scope | One or several assets, fixed for this test | Adjusted as your product changes |
| Testing team | Starts from zero each time you switch vendors | Same team, building on what it learned last time |
| Tracking fixes | A report, updated if you add a retest | A dashboard with the full history across tests |
| Changing vendors | Easy: just don’t renew | Possible at the end of the term |
| Best for | One deal, a company sale, an audit, an unclear future | Annual compliance, recurring enterprise reviews, products that ship often |
Signs a One-Off Isn’t Enough Anymore
If you’ve bought a one-off two years in a row, you’re already testing periodically, just without the better rate or the continuity.
Release pace is the next sign. Ship changes more than about once a month, and most of next year’s code goes live untested. Growth points the same way: a second app, a public API, new user roles, a mobile version. Each one is ground the last report never covered.
Then there’s demand for proof. When several enterprise customers each want a current report, or a SOC 2 Type 2 audit looks across the whole year, a test from March looks old by October.
How to Get the Most Out of a Single Test
A one-off gives you one shot, so the work around it matters as much as the test itself.
Start with timing. Book early enough that, if you add a retest, the fix window closes before the date you need the report. For a SOC 2 Type 2 audit, the test should also land inside the observation period.
Have access ready before kickoff, including a test account for every user role in scope, since testing doesn’t start until the testers can log in. Logged-in testing (gray box, explained in this guide) is where authorization and logic flaws turn up.
Prepare a staging environment for the testers, meaning a copy of your app that real customers don’t use. If staging isn’t practical, testing can also run against production or a hybrid setup; just raise it during scoping.
Keep the report and a record of what you fixed. If next year’s test goes to a different vendor, handing those over saves the new team days of rediscovering old ground.
Then read the report as input for your next decision. Mostly basic issues you’ve since fixed suggest a yearly test is enough. Access-control or logic problems in code you change every month point toward an ongoing engagement.
What You Get With a CYBRI One-Off Test
A one-off with CYBRI is a single, fixed-price engagement with no commitment beyond it, and it includes:
- Manual-first testing led by OSCP-certified senior testers
- A direct line to the testers by email, Slack, or Signal while the work is underway
- Same-day alerts for anything critical an attacker could use right away, instead of waiting for the final report
- An executive summary written for auditors and your board
- Technical findings, each with proof that the issue is real, a CVSS 4.0 severity score (the industry-standard 0 to 10 rating), and specific steps to fix it
- A scope and methodology section stating exactly what was and wasn’t tested
- Report mapping to the frameworks you’re answering to, including SOC 2, ISO 27001, HIPAA, and PCI DSS
- A walkthrough call where the testers go through the findings with your team and answer questions
The methodology follows OWASP’s testing guidance, which covers the common ways web apps and APIs get broken, and larger engagements are also aligned with NIST, so the report holds up when an auditor asks how the test was run.
Many of CYBRI’s SaaS clients have worked with the same team for five or six years, changing the scope as their products grew. A one-off doesn’t commit you to anything like that, but it’s a low-stakes way to see how the team works.
To scope your first test, request a quote.
Frequently Asked Questions
Will every vendor take a one-time project?
Not always. Vendors built around long-term clients may quote a one-off higher or pass on it, especially when the scope is small. Ask early, before your deadline gets close.
Do I need to share my source code?
No. Most one-offs run gray box: the testers log in with accounts you provide but never see your code. Sharing code (white box) lets them dig deeper, and the box-types guide explains when that’s worth it.
Can I share the report with customers?
Yes. The executive summary is written for outside readers, and a shorter summary version can go to customers and auditors without exposing technical detail.
Do I have to fix everything the report finds?
Not all at once. Start with the critical and high-severity findings, since those are what auditors and customers look at first. Lower-risk items can be scheduled into normal development work, or documented as accepted risk if fixing them isn’t worth the effort.
Get a Quote for Your One-Off Test
Every one-off is scoped around what you need tested today and when you need the report, so the quickest way to a price is a short conversation. Contact CYBRI with your scope and deadline, and you’ll get a scoped quote back.
