ISO 29147 Without a Bug Bounty: Do Software Vendors Still Need Penetration Testing?

Does ISO 29147 require penetration testing?

No. ISO/IEC 29147 is a voluntary ISO standard that requires neither a penetration test nor a bug bounty. It defines how an organisation receives vulnerability reports from external finders, coordinates with them, and publishes advisories, while its companion, ISO/IEC 30111, covers internal triage and remediation.

Neither document tells you how to go looking for vulnerabilities in the first place.

That gap is exactly why the question keeps coming up. A vendor can publish a disclosure policy, stand up a security mailbox and a security.txt file, and be broadly aligned with ISO 29147 while never receiving a single report. If nobody is actively probing your product, the pipeline sits idle and your customers have no evidence the software is actually secure. Penetration testing fills that gap, and for vendors without a bug bounty it is usually the only structured source of vulnerability findings they have.

Why this matters for software vendors

ISO 29147 matters to vendors because buyer pressure, not the standard itself, drives adoption. Enterprise procurement questionnaires ask whether you operate a vulnerability disclosure process and whether the product is independently tested, and customer frameworks such as ISO 27001 expect suppliers to be assessed.

A vendor with no testing evidence is harder to approve under those frameworks. Regulation points the same way: the UK Product Security and Telecommunications Infrastructure regime already requires consumer connectable product manufacturers to publish a vulnerability disclosure policy, so buyers now treat a reachable disclosure channel as a baseline signal of vendor maturity. Few UK vendors adopt the standard for its own sake.

A bug bounty is one way to feed that process, but not a cheap one. Bounties need reward budget, staff to triage a noisy stream of duplicate and low-quality reports, and legal comfort with inviting the public to attack production. Many vendors sensibly decide a bounty is premature. The mistake is concluding that no bounty means no testing. A scheduled penetration test from a CREST-accredited firm delivers the findings a bounty would, on a defined scope, a fixed timetable and a predictable budget.

What ISO 29147 actually expects from a vendor

ISO 29147 expects five things from a vendor: a public, easy-to-find channel for receiving vulnerability reports, prompt acknowledgement, enough information exchange with the finder to reproduce the issue, coordinated timing of any public disclosure, and published advisories that help users act.

ISO 30111 then expects a documented internal pipeline that verifies the report, assesses impact, develops a fix and confirms the remediation.

None of that is onerous, and none of it requires paying rewards. What it does require is a process that demonstrably works. This is where penetration testing supports the standard directly: a test produces real vulnerability reports, written to a professional standard, that flow through your intake, triage, remediation and verification pipeline. If acknowledgement takes three weeks, or findings stall between engineering and product, a controlled test surfaces that long before an irritated external researcher does.

What to test in a software vendor’s estate

Scope should follow where a vulnerability would actually hurt you and your customers. For most UK software vendors that means four areas.

• The product itself. The web application, its authentication and session handling, role separation between customer tenants, and business logic. For multi-tenant SaaS, tenant isolation is the single finding class buyers care about most.
• The APIs. Most modern products expose more attack surface through their APIs than their front ends. Dedicated API penetration testing covers authorisation flaws, object-level access control and rate limiting that a browser-driven test can miss.
• The hosting platform. A cloud penetration test reviews the AWS, Azure or GCP configuration the product runs on: identity and access management, storage exposure, network segmentation and secrets handling.
• The perimeter. External infrastructure testing checks what an internet-based attacker can reach beyond the product, including build systems, admin panels and forgotten staging environments.

When we scope engagements for software vendors, we start from the product architecture rather than a URL list: how many distinct roles the application has, how many API endpoints are exposed, whether tenants share a database, and where the CI/CD pipeline and secrets live. Those facts drive the day count far more than page volume. Our penetration testing checklist walks through the preparation in detail.

How an engagement runs

An engagement starts with a short scoping call plus a questionnaire, producing a fixed day count and price. Testing runs over an agreed window, usually one to two weeks, under agreed rules of engagement, and critical findings are flagged the day they are confirmed rather than held for the report.

The report lands within days of testing finishing, with an executive summary you can hand to customers under NDA and technical detail your engineers can act on. A retest of fixed issues then closes the loop and updates the report, the artefact procurement teams actually want to see.

For vendors aligning with ISO 29147, there is a useful extra step: route the test findings through your public disclosure channel and handling process, exactly as an external researcher’s report would arrive. That turns the engagement into a live rehearsal of your intake, acknowledgement and remediation timelines.

What it costs and how scope drives the price

UK penetration testing is priced on scoped effort at a day rate of £1,100 to £1,400. Typical ranges for a software vendor look like this.

Engagement	Typical effort	Typical UK cost
Web application test	4 to 6 days	£4,400 to £8,400
API test	3 to 5 days	£3,300 to £7,000
External infrastructure test	2 to 4 days	£2,200 to £5,600
Cloud configuration review	3 to 5 days	£3,300 to £7,000
Mobile application test	5 to 7 days	£5,500 to £9,800

Scope moves the number: more roles, endpoints, tenants and environments all add days, while combining assessments in one engagement shares scoping and reporting overhead. These are typical UK ranges rather than a price list; the exact figure comes from scoping. Our guide to penetration testing costs in the UK breaks down the drivers in more depth.

How EJN Labs approaches testing for software vendors

EJN Labs is a CREST-accredited UK penetration testing firm, certified to Cyber Essentials Plus and ISO 27001, with all testing delivered by UK-based testers. We work with SaaS and software businesses regularly, so we scope from the architecture, test the product the way a motivated attacker would, and write reports that survive scrutiny from your customers’ security teams. Because we run our own disclosure and remediation processes against the same ISO 29147 and ISO 30111 expectations, we can tell you plainly where your handling process would creak under a real external report. Findings come with practical remediation advice, retesting closes every engagement, and executive summaries are written to be shared with enterprise buyers. Our CREST penetration testing page covers the methodology in full.

Frequently Asked Questions

Does ISO 29147 require a penetration test?

No. ISO/IEC 29147 is a voluntary ISO standard covering how organisations receive and disclose vulnerability reports. It does not mandate penetration testing or a bug bounty, so any testing a vendor commissions alongside the standard is a choice rather than a compliance obligation.

In practice, vendors adopting the standard commission penetration tests anyway, both to find vulnerabilities proactively and to prove their triage and remediation processes work, because customers and procurement teams increasingly ask for both.

Do we need a bug bounty to align with ISO 29147?

No. ISO 29147 requires a way for external finders to report vulnerabilities, such as a security.txt file, a dedicated mailbox and a published disclosure policy. A paid bug bounty programme is one way to provide that channel, not a requirement of the standard.

Many UK software vendors pair a simple disclosure channel with scheduled penetration testing instead, which gives predictable coverage without the operational overhead of running a bounty.

What does penetration testing cost for a software vendor?

UK penetration testing is priced on scoped effort at a day rate of £1,100 to £1,400. A single web application typically takes 4 to 6 days, so £4,400 to £8,400. An API test usually runs 3 to 5 days, around £3,300 to £7,000. Exact pricing depends on scope, so request a tailored quote.

How often should a software vendor run a penetration test?

Test at least annually, plus after significant releases or architectural changes such as new authentication flows, new APIs or a move between cloud providers. Vendors selling into regulated sectors often test more frequently because customer contracts demand recent test reports.

Pairing annual testing with an always-open disclosure channel gives continuous coverage between engagements.

Can a penetration test validate our disclosure process?

Yes. Reports can be submitted through your published disclosure channel during the engagement, letting you measure acknowledgement time, triage accuracy and remediation tracking against the expectations in ISO 29147 and ISO 30111. The vulnerabilities are real, but they arrive from a contracted, vetted UK team.

It is a safe rehearsal, since the same process an unknown finder would trigger gets exercised under contract instead.

Get product security evidence your buyers will accept

If your disclosure policy is written but your product has never been independently tested, the next procurement questionnaire will find the gap. Tell us about your application, APIs and hosting, and we will return a fixed-price scope from a CREST-accredited UK team. Request your penetration testing quote today.