How to prioritise and fix penetration test findings

Start with what could happen

Severity labels help organise a report, but they are not the whole decision. Consider the affected data or action, who can reach the weakness, the conditions required and existing safeguards. A flaw that exposes another customer’s records may deserve attention ahead of a less consequential issue with a similar numerical score.

Understand the evidence

For each finding, identify the affected feature, demonstrated behaviour and recommended change. Ask the assessor to explain uncertainties and prerequisites. Avoid copying confidential reproduction details into widely shared tickets; give developers access through an appropriate private channel.

Create an accountable action plan

Agree priorities with the people responsible for the application and its business risks.

• Assign an owner and a target date to each action
• Consider temporary containment while a full fix is prepared
• Fix shared causes across sibling endpoints
• Record dependencies and operational constraints
• Document any accepted residual risk and a review date

Verify more than the original example

A successful fix should address the underlying rule. If one download lacked an ownership check, inspect other download paths too. Run regression tests, confirm normal user behaviour still works and arrange a retest where appropriate under the agreed service scope.

Keep the report useful

Track status and verification evidence without altering the original findings silently. Revisit the assessment scope after major changes or new sensitive features. Security reports are confidential operational material; store them privately and share access only with people who need it.