A pentest report lands, somebody copies every finding into the ticket queue, and the team starts with whatever is marked critical. We see this often. It feels organised, but it is not triage. Proper triage works out what each finding means in your environment, what should happen next and who can make it happen.
Scanner severity is a starting point. It may reflect a standard score or the tester’s view of the issue in isolation. Your application, deployment, data, and compensating controls determine the real priority. A medium finding on an internet-facing administrative path may deserve action before a high finding in an isolated test environment. The report label should prompt investigation, not end it.
Confirm what is actually exploitable
Begin with the evidence. Identify the affected asset, request path, user role, input, response, and preconditions. Determine whether the tester demonstrated impact or reported a plausible weakness that needs confirmation. A finding can be technically valid while its practical exploitability depends on a condition that is absent in production.
Ask specific questions:
- Can an attacker reach the affected component from the internet or only from a trusted network?
- Does exploitation require an authenticated account, a privileged role, or access to another user’s identifier?
- Is the vulnerable code enabled and used in production?
- Do rate limits, network controls, or runtime protections prevent or materially constrain the demonstrated technique?
- Can the behaviour be reproduced safely in a controlled environment?
Do not close a finding simply because one proof-of-concept request fails. Configuration differences, test data, and defensive controls can change the result. Record the evidence for the decision and ask the tester for clarification when the reproduction steps are incomplete.
Evaluate exposure and data sensitivity
Exposure describes who can reach the weakness and under which conditions. An unauthenticated public endpoint has a different attack surface from an internal administration tool. Yet internal does not mean harmless. A compromised employee account, exposed VPN credential, or overly broad service identity can make an internal path reachable.
Next, identify the data and actions within reach. Avoid broad labels such as “sensitive data” when the system owner can name the records involved. Determine whether the weakness exposes account details, authentication material, business documents, operational metadata, or no stored data at all. For integrity issues, identify which state an attacker could change. For availability issues, identify the service boundary and recovery path.
Data sensitivity changes the consequence, but it is not the only factor. An authorisation flaw that reveals low-sensitivity records may expose a reusable object-access pattern. The same missing check could protect more consequential actions elsewhere.
Look for connected findings
Reports usually describe findings separately because that format is easier to read and track. Attackers can combine them. A low-severity information leak might reveal internal identifiers. A second weakness may accept those identifiers without checking ownership. Weak session controls could make the combined path easier to repeat.
During triage, map what each finding provides: access, information, execution, persistence, or a way around a control. Then ask whether another finding supplies the missing precondition. Do the same with known system behaviour that may not appear in the report, such as public registration, predictable account states, shared integration credentials, or broad cloud permissions.
Treat a credible chain as one risk scenario for prioritisation, while keeping the underlying fixes as separate work items when different teams own them. This preserves technical clarity without understating the combined impact.
Describe business impact without exaggeration
Technical impact is what an attacker can do. Business impact is what that action changes for the organisation or its customers. The connection should be concrete.
For example, arbitrary access to another tenant’s invoices could create confidentiality, contractual, and customer-support consequences. Changing payout details could lead to unauthorised transactions and a difficult reconciliation process. Disabling a background worker may delay an internal task without taking down the customer-facing service. These are different situations and should not share a generic “reputational damage” statement.
Use uncertainty honestly. If the team cannot yet determine the volume of accessible records, say so and create an investigation task. Do not turn the highest imaginable outcome into the expected outcome. Triage needs a defensible basis for action, not dramatic language.
Account for fix complexity and risk reduction
Priority and delivery order are related, but they are not identical. A serious architectural flaw may take weeks to correct. A narrow configuration change might reduce exposure on the same day. The plan can include an immediate containment step, a durable fix, and any cleanup needed after deployment.
Estimate complexity with the engineers who own the system. Consider code changes, schema migration, client compatibility, deployment dependencies, operational load, and the chance that a rushed patch will break an existing control. A difficult fix should not be downgraded because it is inconvenient. It needs a staged plan and a clearly accepted interim risk.
Also watch for fixes that address only the reported example. If one endpoint lacks an object-level authorisation check, search for the same access pattern in related handlers. If a secret appears in a repository, removing the string is not enough. Credentials confirmed valid or exposed must be rotated, their use traced, and the exposure path corrected.
Assign ownership at the right level
Every accepted finding needs one accountable owner, even when several teams contribute. Ownership belongs with the person who can coordinate the fix and report its status, not automatically with the security team that received the report.
Application flaws may belong to a product engineering team. Cloud permissions may belong to a platform team. A business workflow weakness may require a product owner to decide which actions need additional approval. Security can advise, review, and track risk, but it cannot implement every change on behalf of the system owner.
A useful ticket contains the affected scope, evidence, risk scenario, agreed treatment, target date, owner, dependencies, and verification method. Link back to the original report rather than copying screenshots without context.
Verify the fix and plan the retest
A ticket marked complete means the implementation work ended. It does not prove that the weakness is gone. Verification should reproduce the original behaviour and test nearby cases that the fix could miss. For access-control findings, test multiple roles, object owners, tenants, methods, and alternate endpoints. For configuration findings, inspect the deployed environment rather than relying on a source change alone.
Choose the verification route during triage. A focused internal check may be enough for a simple, well-understood change. A tester retest is appropriate when exploitability was complex, the fix changed a trust boundary, several findings formed a chain, or independent evidence matters to the recipient of the report.
Keep the retest scope and environment clear. Give the tester the finding references, deployment version, relevant accounts, and any deliberate constraints. If the original finding remains, reopen it with the new evidence rather than creating a duplicate.
Turn the report into a working plan
The finished triage should leave the team with fewer unknowns. Each finding has a stated exposure, exploitability assessment, affected data or action, possible chains, business consequence, treatment, owner, and verification route. Disputed items have explicit questions and evidence requests.
Review the plan together while the report is still fresh. Security, engineering, operations and product owners will usually see different parts of the same scenario. That conversation is what turns a static report into a working remediation plan. Severity helps start the discussion. Evidence and context decide the work.
If you want to see how that handover can look, review our fictional sample pentest remediation report. The 12-page PDF shows priorities, owners, work packages and the evidence required before a finding is treated as closed.