> grep 'implement best practices' report.pdf && echo 'nobody knows what this means'_
A penetration test report lands on the IT manager's desk. It contains 34 findings, clearly described, well-evidenced, with an attack narrative and a Real World Risk Score for each. The IT manager understands the risk. They agree with the priorities. They assign the findings to their team and set a 30-day remediation target for critical and high findings.
Six weeks later, eleven findings remain open. Two of the open findings are critical. The IT manager checks with the team. The infrastructure engineer says: "The report says 'harden the Active Directory configuration.' I don't know which settings they mean. I've spent three hours researching it and I'm not confident I've found the right GPO." The developer says: "The report says 'implement parameterised queries.' The finding is in a legacy PHP application with 40,000 lines of code and no test suite. I don't know where to start." The security analyst says: "The report says 'implement network segmentation between the office and production VLANs.' That's a six-month project involving procurement, network redesign, and change management. It wasn't scoped as a 30-day fix."
The findings were correct. The risk assessment was sound. The remediation guidance was useless — not because it was wrong, but because it wasn't specific enough for the people who actually have to implement it. "Harden Active Directory" is an intention, not an instruction. "Implement parameterised queries" is a principle, not a plan. "Implement network segmentation" is a project, not a remediation step.
"Implement best practices" is the most expensive sentence in cybersecurity reporting. It transfers the cost of research from the tester — who already understands the vulnerability — to the engineer — who doesn't. Every hour the engineer spends researching what "best practices" means for this specific finding is an hour the tester could have saved them with two additional sentences in the report.
Penetration test findings are remediated by three distinct teams, each with different tools, different vocabularies, and different constraints. A finding that affects application code goes to the development team. A finding that affects servers, networking, or Active Directory goes to the infrastructure team. A finding that requires policy changes, monitoring configuration, or detection rules goes to the security team. Writing remediation that works for all three requires understanding how each team operates.
| Team | What They Control | What They Need From the Finding | What Blocks Them |
|---|---|---|---|
| Development | Application code, APIs, authentication logic, input validation, session management, data handling, CI/CD pipelines. | The vulnerable code path or endpoint. The specific input that triggers the vulnerability. A code example showing the fix — in the language and framework the application uses. Guidance on testing the fix. | Vague remediation that doesn't reference the application's technology stack. "Use parameterised queries" without showing the specific code pattern for their framework. No indication of which endpoints are affected. No test case to verify the fix. |
| Infrastructure | Servers, operating systems, Active Directory, Group Policy, network devices, firewalls, DNS, DHCP, virtualisation, cloud infrastructure. | The specific setting, policy, or configuration to change. The exact path — Group Policy Object, registry key, configuration file, CLI command. The expected impact on other systems. A verification step to confirm the change worked. | "Harden the configuration" without specifying which configuration. "Disable legacy protocols" without naming them or providing the GPO path. No impact assessment — the engineer doesn't know if the change will break a production service. |
| Security / SOC | SIEM rules, EDR policies, detection logic, monitoring configuration, incident response playbooks, access control policies. | The specific detection gap — which technique wasn't detected and why. The log source and event ID needed. A sample detection rule or the logic for one. The expected alert volume and false positive rate. | "Improve monitoring" without specifying what to monitor. "Detect lateral movement" without providing the event IDs, log sources, or rule logic. No guidance on tuning to avoid false positives. |
Every finding in a pen test report should contain enough information for the responsible team to understand the problem, reproduce it, fix it, and verify the fix — without needing to phone the tester, research the vulnerability, or guess at the remediation.
| Component | What It Contains | Why It's Essential |
|---|---|---|
| 1. Affected asset(s) | The specific hostname, IP address, URL, endpoint, application, or service affected. Not "multiple servers" — the actual list. | The team needs to know where to apply the fix. "SMB signing not enforced" affecting 12 unnamed hosts is unactionable. The same finding with a table listing all 12 hostnames is a work order. |
| 2. Reproduction steps | A step-by-step guide to reproducing the vulnerability — the tool, the command, the input, and the expected output. | The engineer needs to see the vulnerability before they can fix it. If they can't reproduce it, they can't confirm it exists, can't test the fix, and will often deprioritise it as "possibly a false positive." |
| 3. Evidence | Screenshots, request/response pairs, command output, or tool output that proves the vulnerability exists. Timestamped where relevant. | Evidence removes ambiguity. It proves the finding is real, shows exactly what the tester observed, and provides a baseline for comparison after remediation. |
| 4. Root cause | Why the vulnerability exists — not just what it is. A misconfigured GPO, a missing input validation check, a default credential that was never changed, a service account created during initial setup and forgotten. | Understanding the root cause prevents recurrence. Fixing the symptom without addressing the cause means the same class of vulnerability will reappear. Root cause also identifies whether the finding is an isolated mistake or a systemic pattern. |
| 5. Specific remediation | The exact change required: the GPO path, the configuration parameter, the code change, the CLI command, the permission to remove. Written in the language of the team that will implement it. | This is where most reports fail. "Enforce SMB signing" is a principle. "Computer Configuration → Policies → Windows Settings → Security Settings → Local Policies → Security Options → Microsoft network server: Digitally sign communications (always) → Enabled" is a remediation. |
| 6. Impact assessment | What the fix might break. Will enforcing SMB signing cause a 1–3% performance impact on file server throughput? Will disabling TLS 1.0 break connectivity for legacy clients? Will parameterising this query change the application's behaviour? | Engineers won't implement a change if they don't know what it will break. An impact assessment gives them the confidence to proceed — and the information to schedule the change appropriately. |
| 7. Verification step | How to confirm the fix worked. The command to run, the test to perform, the expected output after remediation. "After enabling SMB signing, attempt nmap --script smb2-security-mode -p 445 target — output should show 'Message signing enabled and required.'" |
Without a verification step, the engineer implements the fix and hopes it worked. With one, they implement the fix and prove it worked. The difference is the difference between a finding marked "remediated" and a finding confirmed as remediated. |
| 8. Effort and dependency | An honest estimate of the effort required (15 minutes, 2 hours, 3 days, 6-month project) and any dependencies on other fixes, procurement, change windows, or third parties. | A 30-day remediation target for a finding that requires a 6-month network redesign sets the team up for failure. Honest effort estimates let the IT manager plan realistically and set appropriate deadlines. |
Infrastructure teams think in Group Policy paths, registry keys, CLI commands, and configuration files. The remediation needs to speak their language — with the exact settings to change, the exact values to set, and the exact command to verify.
The first remediation requires research. The second requires only implementation. The engineer reads it, opens Group Policy Management, navigates to the path, enables the setting, and runs the verification command. The finding is fixed within the hour — because the tester invested five minutes writing the specific guidance that saved the engineer two hours of research.
Development teams think in code paths, endpoints, frameworks, and test cases. They need to know which endpoint is vulnerable, what input triggers the vulnerability, what the fix looks like in their technology stack, and how to write a test that confirms the fix works.
The developer reads this finding and knows exactly what to do: open CustomerController.php, go to line 142, replace the concatenated query with the prepared statement shown, run the test payload, and add a CI/CD check. They don't need to research PDO syntax, search the codebase for the vulnerable endpoint, or guess which parameter is injectable. The tester did that work already.
Security teams think in detection rules, log sources, event IDs, and policy configurations. They need to know which technique wasn't detected, which log source provides the telemetry, what the detection logic looks like, and how to tune it to avoid drowning in false positives.
The security analyst reads this and knows: the parser needs updating (specific field), the rule logic is provided (specific conditions and exclusions), the tuning approach is defined (7-day audit mode, expected steady-state alert volume), and the verification step uses the exact tool and command that tests the detection. They can implement and validate the rule within a day.
One of the most damaging patterns in pen test reporting is treating all findings as equal-effort remediations. "Disable LLMNR" takes 15 minutes. "Implement network segmentation between office and production" takes six months and a procurement cycle. Setting a blanket 30-day remediation deadline for both guarantees that the network segmentation finding will miss the deadline — and the team's credibility suffers for a failure that was inevitable from the start.
| Effort Category | Examples | Realistic Timeline | Report Guidance |
|---|---|---|---|
| Quick win | Disable LLMNR. Change a password. Enable a GPO setting. Remove an unnecessary share permission. Revoke an orphaned OAuth consent. | Hours to days | "This fix takes approximately 15 minutes to implement and has no dependencies. Implement immediately." The report should flag quick wins explicitly — these are the findings that show fast progress. |
| Standard remediation | Deploy SMB signing across the domain. Migrate a service account to gMSA. Update a web application's authentication flow. Add detection rules and tune for false positives. | Days to weeks | "Estimated effort: 2 days including testing and change management. Requires a change window for SMB signing rollout. Test on a pilot group of 10 servers before domain-wide deployment." |
| Project-level change | Implement network segmentation. Deploy NAC (802.1X). Migrate from on-premises AD to Entra ID. Rewrite a legacy application's authentication layer. | Months to quarters | "This is a strategic remediation requiring procurement, design, and staged implementation. Recommend scoping as a dedicated project with a 3–6 month timeline. In the interim, apply compensating control: restrict VLAN access to authorised MAC addresses via port security." |
| Accepted risk | A legacy system that cannot be patched because the vendor no longer supports it. A business process that requires a configuration the tester recommends changing. | N/A — managed, not fixed | "If this finding cannot be remediated due to business or technical constraints, document the accepted risk and implement compensating controls: isolate the system on a dedicated VLAN, monitor all traffic to and from it, and restrict access to named administrators." |
Honest effort estimates — included in the finding itself — let the IT manager build a realistic remediation plan rather than a fantasy one. Quick wins get done immediately. Standard remediations get scheduled. Project-level changes get scoped and funded. And accepted risks get documented with compensating controls rather than ignored.
A finding that doesn't get fixed is a finding that didn't matter. And the most common reason findings don't get fixed isn't disagreement with the severity, lack of budget, or technical impossibility. It's that the remediation guidance transferred the cost of research from the tester to the engineer — and the engineer, facing a queue of 34 findings, 200 other tasks, and a remediation that says "implement best practices," puts it in the backlog.
Specific remediation closes the gap. A GPO path instead of "harden Active Directory." A prepared statement in the application's framework instead of "use parameterised queries." A SIEM rule with event IDs, field names, and tuning guidance instead of "improve monitoring." An effort estimate that distinguishes a 15-minute quick win from a 6-month project. A verification step that lets the engineer prove the fix worked.
The five minutes the tester spends writing specific remediation saves the engineer two hours of research — and makes the difference between a finding that gets fixed in a day and a finding that sits in the backlog for six months. Specificity is the cheapest investment in cybersecurity — and the one with the highest return.
Our reports include GPO paths, code examples, SIEM rule logic, effort estimates, impact assessments, and verification steps for every finding — because a finding that doesn't get fixed is a finding that didn't matter.