# Pen test reports land in November. Code freezes land in December.

Most of what a penetration test costs arrives after the report: engineering time nobody reserved, on code nobody owns, before a freeze nobody moved. How to sort findings by the work they need, name owners and book the retest now.

By Precision Code Studios. Published October 20, 2026. Category: Security. https://www.precisioncodestudios.com/insights/pen-test-findings-before-the-code-freeze

The report arrives on a Thursday in mid-November. Forty pages, seventeen findings, two of them rated high. The readout call goes well: the tester walks through each issue, the engineers ask sensible questions, everyone thanks everyone. Then somebody asks who is going to fix them, and the call goes quiet.

It is a familiar week. The sprint is committed to a January launch. The worst finding sits in a service written by an agency whose contract ended in the spring. The code freeze starts in four weeks, and the enterprise customer who asked for the test wants to hear, before renewal, that the high findings are closed.

That stall is normal. According to Cobalt's State of Pentesting Report 2025, built from the company's own testing data, organisations resolve about 48% of the issues found in penetration tests, and 69% of the serious ones. The median time to resolve a finding was 67 days, against the two-week target that about three-quarters of organisations said they work to. Finding the problems is the part companies have learned to buy. Fixing them is where they get stuck.

## The test has a price. The fixing does not.

Buyers compare penetration test quotes carefully: days of testing, scope, the testers' credentials. Almost nobody puts a number next to what happens after the report, though that is the only part that lowers your risk. A finding you have documented and not fixed is still open, and now there is a paper trail showing you knew about it.

Remediation is engineering work, and it lands on whichever team owns the code. That team rarely has slack in the fourth quarter. So the fixes join the backlog behind the features, the features win, and the findings age. When next spring's security questionnaire asks whether every high-risk finding from the last test was remediated, someone has to choose between an awkward answer and an untrue one.

## Severity says when. The shape of the fix says how much.

A report ranks findings by severity, usually some version of critical, high, medium and low. That tells you urgency. It tells you very little about cost, and cost is what decides whether a fix fits before the freeze. Before planning anything, sort every finding a second time, by the kind of work it needs.

- **A setting.** A missing security header, a storage bucket anyone can read, an outdated TLS version, a default admin password. Hours of work, usually for whoever runs the infrastructure, with little risk of breaking anything.
- **A spot fix.** One endpoint that trusts an ID sent from the browser, one database query built by gluing strings together. A day or two, including the test that proves it stays fixed.
- **A pattern.** The same mistake, built many times. The report lists three endpoints that skip an ownership check; the codebase has sixty written the same way. Weeks rather than days, and the shape most often underestimated.
- **A design flaw.** How customers' data is kept apart, how sessions work, how secrets reach services. Months of work, an architect's attention, and something to hold the line while the real fix is built.

*Figure: A grid with severity (high, medium, low) as rows and fix shape (setting, spot fix, pattern, design) as columns. Each cell gives the action; high severity with pattern shape is highlighted: contain now, fix the class. Sort each finding twice. The highlighted cell looks like three tickets and is usually a small project.*

The cell that hurts is high severity crossed with pattern. In the report it looks like three tickets. In practice it is a small project: someone has to search the whole codebase for the class of mistake, settle on one correct fix, apply it everywhere, and add a test that fails if anyone builds it the old way again.

> **Instances, not classes:** Testers usually sample. When a report lists three examples of a mistake, assume the rest of the code was built the same way until a search proves otherwise.

Design findings call for a different kind of honesty. They will not be fixed before the freeze, and pretending otherwise produces a rushed change to the riskiest part of the system in the worst fortnight of the year. Put a compensating control in place instead, such as a firewall rule, a feature switched off, or an alert on the exact path the tester used. Then write down the real plan and give it a date in the new year.

## Give every finding a name before the readout ends

Ownership is where the gap opens. The testing firm treats fixing as out of scope. The agency that wrote the affected service has gone, or its contract covers new features only. The in-house team did not write that code and is busy shipping the code it did write. Each position is reasonable, and together they mean nothing gets fixed.

End the readout with a short record for every finding:

- **An owner.** A person's name. A team name on a security ticket usually means the ticket waits.
- **Its shape and a target date.** Taken from the second sort, so the date reflects the work rather than the severity label.
- **An interim control.** For anything that will not ship before the freeze: what limits the damage until it does.
- **A retest date.** Agreed with the testers now, because their calendar fills up in December too.

Expect the first half-day on each finding to go on reproducing it. Reports tend to show a captured request and a screenshot, which convinces an auditor but leaves an engineer, working on a local copy with different data, guessing at the setup. Ask the testers for the raw requests, and for twenty minutes on a call with whoever is fixing the high findings. It is the cheapest time in the whole exercise.

## Work back from the freeze

Count the days. Take 2026 as the worked example: a report in the week of 16 November, US Thanksgiving on 26 November and a freeze from 14 December leave about four working weeks, and you want the last of them for the retest. The dates move each year; the squeeze does not. Laid out on a calendar, it becomes obvious which findings fit and which do not. Better to see that in October than in the second week of December.

*Figure: Timeline from 19 October 2026 to 11 January 2027: testing to mid-November, report on 16 November, three weeks of fixing, retest in the week of 7 December, code freeze 14 December to 8 January. Design fixes get an interim control first. A typical fourth-quarter test, using 2026 dates. Once the retest and the holiday are on the calendar, the fixing window is short.*

Three decisions belong on that calendar before the report arrives. First, agree a freeze exception for security fixes, in writing, with whoever owns the freeze; otherwise a finished fix sits in a branch until January because nobody wants that argument over the holidays. Second, if testing has not started, ask the testers to release confirmed high findings as they find them rather than holding everything for the final report. That alone can hand back a week or two. Third, book the retest for the week before the freeze, so you go into the holidays with evidence rather than intentions.

The retest matters more than it looks. If you handle card payments, PCI DSS requirement 11.4.4 says exploitable findings must be corrected and the test repeated to verify the corrections. Enterprise security questionnaires often ask the same thing in plainer words. A retest letter showing the high findings closed is the document a customer's security team wants. The original report, on its own, mostly shows what was wrong.

## Questions to settle before you sign the test

These work with any testing firm, including one you have used for years.

- **Is a retest included?** How many rounds, within what window after the report, and does it cover medium findings or only high ones?
- **Will findings arrive as they are confirmed?** Waiting for the final report spends days you need for fixing.
- **Can an engineer rerun each finding?** Ask to see a redacted finding from a past report. If it is all narrative and screenshots, the fixing will start slowly.
- **Will the testers say where they sampled?** A note that five similar endpoints were checked and three failed turns a spot fix into a pattern before it surprises you.
- **Who fixes, and whose hours are reserved?** This one is for you, not the vendor. If the answer is the team already committed to a launch, it has not been answered.

## When to bring in outside hands, and when not to

Plenty of reports need no outside help. If most findings are settings and spot fixes and your own engineers wrote the code, they will fix it faster than anyone you could bring in, because they will not spend the first week learning the system. Spend the money on a deeper test next year instead.

Outside engineers earn their place in three situations. The findings are pattern-shaped and sit in code nobody on staff wrote. The team that could fix them is committed to a date that cannot move. Or a design finding needs a few weeks of an architect you do not employ. In each case the useful arrangement is narrow: a defined set of findings, the testers' evidence, access to the code, and a retest at the end that decides when the work is done.

Pattern findings suit AI-assisted engineering for an unglamorous reason. Once the correct fix has been chosen, applying it is the same small change made many times, and the test that proves it can be written once and run against every instance. That is the kind of work that goes quickly with good tooling. The hard part sits on either side of it: deciding what the correct fix is, and confirming that the search found every instance, not only the ones that happened to match the first pattern someone searched for. Insist on seeing that confirmation, whether the fix comes from your own team or anyone else's.

When you decide which findings can wait until spring, remember who reads the report next. Next year's tester will start with this year's findings, and whatever is still open is the first door they will try. They are unlikely to be the first to try it.

## The short film: transcript

A pen test buys you a list. The fixing is the bill.: the short version (1:19).

Companies compare penetration test quotes down to the day, then budget nothing for the engineering that follows the report. Those weeks are the only part that lowers the risk.

Testing isn't where it breaks down. The fixes land on a team already committed to features, the features win, and the open items quietly age past every target anyone set.

So before you plan anything, go through the report a second time and ask what kind of work each item needs. That, far more than the red label, tells you whether it fits before the holidays.

Skip the search and the job resizes itself halfway through December, when three tickets turn into a small project. Pick one correct fix, apply it everywhere, and add a test that fails if anyone builds it the old way again.

A report in mid-November leaves about four working weeks before a December freeze, and the last of them belongs to the retest. The retest letter is what auditors and customers will ask to see.

Next year's tester will start with whatever this year's report left open. So will anyone else looking for a way in.

Read the full article at Precision Code Studios.