How to Run a Penetration Testing Program in 2027

Nobody is hired to run a penetration testing programme. You get given one. It usually arrives as a compliance obligation, a customer requirement or a board question, and six months later you are coordinating three vendors, four engineering teams and a spreadsheet nobody trusts.

The vendors who write about this describe their own delivery process and stop at the report. That is a testing engagement, not a programme. A programme is the machine around the engagement: how work comes in, how testers are chosen and scheduled, how findings from different sources become one backlog, how fixes get routed and verified, and how you report it upward without being asked for the raw report.

This is the operating model, with the artefacts. Everything below is something you can copy into Confluence on Monday.

What a programme is, and when you need one

A single test answers "is this thing secure right now." A programme answers "is our security posture improving, and can I prove it." The difference is state: a programme carries findings, owners, dates and verification across engagements, so the second test is measured against the first.

You need one when any of these is true:

• You run more than four engagements a year, or use more than one vendor.
• Findings from testers, scanners and bug bounty arrive in different formats and nobody reconciles them.
• Someone outside security, an auditor, a customer or the board, asks for status between tests.
• You cannot answer "how many critical findings from the last test are still open" in under a minute.

That last one is the real test. If answering it means opening a PDF, you have engagements, not a programme. We built a five level pentest management maturity model if you want to score where you currently sit before reading on.

The operating model in one view

Each stage below gives you the artefact that makes it work. The stages are deliberately boring. Programmes fail at the handoffs, not inside the stages.

Stage 1: intake and scoping

The most expensive failure in the whole lifecycle happens here, and it looks harmless: a team asks for "a pentest on the new API" and somebody books one. Three weeks later the tester finds the API is one of nine services behind a gateway, half of which are out of scope, and the report is useless to everyone.

Fix it with a standing intake form. Every request answers the same questions before anyone talks to a vendor.

Tier the requests as they come in. A public facing payment flow and an internal admin tool do not deserve the same depth, and treating them equally is how programmes run out of budget in Q3. Three tiers is enough: critical (internet facing, handles money or regulated data, annual deep test plus retest), standard (internet facing, lower blast radius, annual test), light (internal, low sensitivity, scanning with a periodic manual review).

Stage 2: vendor selection and scheduling

Run a **panel of two or three vendors**, not one. A single vendor gets comfortable, and testers who have seen your estate three times in a row stop finding new things. Rotating also gives you a real price reference, which single vendor shops never have.

Three scheduling rules save more pain than any tooling decision:

• Book against the release calendar, not the security calendar. A test that lands in a code freeze finds nothing anyone can act on. A test that lands the week before a major release produces findings nobody has capacity to fix.
• Confirm environment and credentials fourteen days out, then again at seven. Lost test days are the single largest source of wasted spend in this category, and they are almost always access problems.
• Leave a retest window in the original purchase order. Buying the retest separately turns a two week fix cycle into a six week procurement cycle. Negotiate it at contract time, when you have leverage.

If you are choosing or replacing the platform that holds all this, we compared nine options in the best pentest management platforms.

Stage 3: consolidating findings from multiple testers

Here is where the job gets genuinely hard, and where no vendor blog helps, because the problem only exists if you have more than one of them.

You will receive the same issue described three ways: a scanner calls it TLS version weak, a tester calls it "Deprecated TLS 1.0 enabled on edge", and a bug bounty report calls it "Downgrade possible on api.example.com". If you import all three you get three tickets, three owners and an inflated open count that makes your trend chart meaningless.

Normalise severity on arrival. Vendors use CVSS v3.1, CVSS v4.0, their own five point scale and occasionally adjectives. Pick one internal scale, publish the conversion rule, and apply it at import rather than arguing per finding. Keep the original rating in a separate field, because an auditor will eventually ask why a vendor's "high" is your "medium", and "we have a documented conversion rule" is a complete answer while "we disagreed" is not.

Stage 4: severity, SLAs and remediation routing

A finding without an owner and a date is a note. The SLA is what converts the report into work the engineering organisation recognises.

Route findings into the tracker engineering already uses. Not a security portal they have to remember to check, not a shared inbox. If the fix does not appear in the sprint board, it does not get done, and every hour you spend persuading people otherwise is an hour you lose.

Exceptions need the same rigour as fixes. An accepted risk gets a named approver, a stated reason, a review date and an expiry. Risk acceptances that never expire are how a three year old critical finding ends up in an audit, with nobody able to explain who agreed to it.

Stage 5: retest verification

Retesting is the stage everyone underfunds and the only one that produces evidence. A programme without verification is a programme that reports fixes it cannot prove.

Two practices separate programmes that verify from programmes that claim to:

Never let the fixing engineer verify their own critical finding. Not because they are dishonest, but because they will test that their fix works rather than that the attack fails. Those are different questions and only the second one matters.

Decide upfront what happens when a retest fails. Most teams have no answer, so a failed retest quietly becomes a new ticket and the original closes. The original must stay open, the clock must keep running, and the failure should be visible. Otherwise your mean time to remediate measures how fast you close tickets, not how fast you fix things.

Automated retesting changes the economics here substantially, because the cost of verification is what drives teams toward self attestation. SLASH runs retests automatically rather than booking them as new work, which is the mechanism that makes independent verification affordable at volume.

Stage 6: reporting to the board

The board does not want findings. They want to know whether risk is going down and whether the money is working. Six numbers answer that. Anything more and the conversation becomes about the chart.

Say what the programme cost and what it changed, in the same slide. "Four engagements, £62,000, 11 criticals found, 11 closed inside SLA, mean time to remediate down from 41 days to 19" is a budget conversation that goes well. A heat map is a budget conversation that goes nowhere.

Who does what

Programmes fail at handoffs, so write the handoffs down.

Questions programme owners ask

**How many penetration tests should we run a year?** Tier your assets rather than picking a number. A typical mid sized SaaS runs one deep annual test per tier 1 asset, a lighter annual test on tier 2, and continuous scanning with a periodic manual review on tier 3. That usually lands at four to eight engagements a year. Compliance may set a floor, for example PCI DSS requires annual testing and after significant change, but a floor is not a programme.

Should we use one vendor or several? Several, rotated. Two or three on a panel gives you fresh perspective, a genuine price reference and cover when one is booked out. The cost is that you must normalise their output yourself, which is exactly what the consolidation stage above exists to do.

Who should own the penetration testing programme? Someone in security with operational authority, not a tester and not a compliance analyst. The role is roughly 60% coordination, 30% data work and 10% technical judgement. The common failure is handing it to the best technical tester, who then does the job well and resents every hour of it.

How do we handle a finding engineering says is a false positive? Put the burden of proof on the dispute, not the finding. The team disputing supplies evidence, the original tester reviews it, and the outcome is recorded either way. Never let a verbal dismissal close a finding, and never let a dispute stop the SLA clock. If the dispute is upheld, the clock stops retroactively.

What is the difference between a pentest programme and vulnerability management? Vulnerability management is continuous, scanner driven and covers known issues at scale. A pentest programme is episodic, human driven and finds logic and chain issues scanners cannot. They share a backlog and should share an SLA, but they are different intake streams and conflating them makes both reporting lines meaningless.

How long before a programme shows results? Two cycles. The first engagement after you put intake and SLAs in place produces a worse looking number, because you are finally counting properly. The second shows the trend. Tell your exec sponsor this in advance or the first report will look like a failure.

Starting from nothing

If you have none of this today, build it in this order over one quarter: **intake form first**, because it costs nothing and immediately improves every engagement; **SLA mapping second**, because it converts findings into recognised work; **consolidation third**, because it is the most work and pointless without the first two; **board metrics last**, once you have two cycles of honest data.

Do not start with tooling. A programme that works on a spreadsheet can move to a platform in a week. A platform bought to fix a programme that has no intake form will reproduce the mess faster.