The annual pentest was built for companies that ship once a year

If you run a small team, there is a decent chance nobody has ever tried to break into what you built. Not because you don't care. Because the way the industry sells security testing was designed for a different kind of company.

A penetration test, a pentest, is when someone is paid to attack your product the way a real attacker would, and to write down what they got into. It is the closest thing to ground truth security has. It is also, in its classic form, a project: you scope it, you book a firm, you wait a few weeks, you get a PDF, you fix what you can, and you do it again next year.

That rhythm made sense when software shipped in releases. It stops making sense the moment your team merges to production several times a day.

What the yearly audit quietly assumes

The annual pentest rests on three assumptions, and every one of them is false for a small team shipping fast.

1. Your product is roughly the same product a year later. For most teams under twenty people, it isn't. The endpoints tested in March may be gone by June, and the ones that matter in December did not exist when the report was written.
2. Someone will read the report and drive the fixes. A sixty-page PDF assumes there is a security person on the other end. When there isn't, the report goes to whoever is least busy, the criticals get patched, and the rest becomes a ticket that never quite reaches the top of the sprint.
3. The cost is proportionate to the risk. A boutique pentest in Europe typically runs from a few thousand to a few tens of thousands of euros, for a fixed scope, once. For a company with two engineers, that is not a security budget; it is a fundraising line item.

So the honest outcome for a lot of small teams is not "we do a pentest once a year". It is "we have never done one", and the plan is to do one when a customer asks. That is precisely the moment you have the least time to fix anything it finds.

Meanwhile, nobody is waiting for your schedule

The other side of the equation does not run on an annual calendar either. Honeypot research has shown for years that a freshly exposed host receives its first automated probes within minutes of going online, and that new domains and certificates are picked up by scanners within hours. None of that is targeted at you. It is the background noise of the internet, and it is what finds the forgotten staging environment, the debug endpoint left open, the API key committed on a Friday.

This is the gap the industry is now naming out loud. Intruder held a literal funeral for the annual pentest this year. HackerOne's tagline is "Security, Continuously". Strix talks about pentesting every pull request. They are all describing the same shift: security testing moving from a project you book to something that runs alongside your delivery.

What "continuous" actually means

The word gets used loosely, so here is the practical definition. Continuous pentesting means three things happening without anyone having to schedule them:

• It runs on change, not on a date. When you ship, whatever changed gets looked at again. When you don't, nothing burns budget re-testing what was already tested.
• It watches what you expose, not just what you told it about. New subdomains, expiring certificates, a fresh vulnerability published in a library you depend on. These show up on their own, because the thing you are least likely to test is the thing you forgot you had.
• It produces findings you can act on, not reports you have to interpret. Each issue says what it is, what someone could actually do with it, and the specific change that closes it. If a finding cannot be reproduced, it does not reach you.

Why this matters more when you have no security team

The vendors leading this shift are, mostly, selling to companies that already have security engineers. For them, continuous testing is an efficiency gain. For a team with nobody whose job is security, it is something else: it is the first time testing fits the way they work at all.

A founder cannot read a pentest report between two customer calls. A founder can read: "Your password reset link works more than once. Someone who intercepts it can take over the account. Here is the two-line change; here is the pull request." That is the level at which continuous pentesting has to operate to be useful outside a security team. Not by accident, it is also the level at which a good senior engineer would explain it to you.

The question is no longer whether you can afford a pentest. It is whether you can afford to be the only one not testing your product.

What to do this week, whether you use Orja or not

1. List what you actually expose. Every domain and subdomain, every API that answers without a login, the cloud account it all runs on. Most small teams discover something on this list they had forgotten.
2. Run one outside-in pass, today. Not a full audit, just one look at your product from the outside, the way an attacker's first ten minutes would go. If you have never done this, it will find something.
3. Make the next one automatic. Whatever you use, wire it to your deploys. A test you have to remember to run is a test that will stop running the first busy month.
4. Keep the answer ready. Sooner or later a client or an investor sends the security questionnaire. The team that already has last week's findings and fixes answers it in an afternoon. The team planning "a pentest at some point" loses the deal or the week.

This is what Orja is built for: continuous penetration testing for small teams, from the outside, with every finding verified and handed back with the fix. If you have launched something and nobody has ever tried the door, put in your domain. The first report is free.