Match the results to the engagement
Start with the question you commissioned the assessment to answer. Are the agreed systems listed? Does the assessment period match the version you care about? Which areas were accessible and which credentials were missing? These details determine the decisions the report can support.
OWASP recommends presenting scope, limitations, a summary and technical findings clearly. A well-defined report helps both management and the people implementing changes.
For a consultancy or IT provider, ownership also matters. Does a finding concern your own platform, a shared service or one customer project? A clear assignment prevents a suitable action from being sent to the wrong team. [1]
Compare objectives and assessment depth before commissioning work
Separate a signal, a confirmed observation and its impact
An automated signal is a starting point for assessment. A confirmed observation needs a traceable connection to the tested system. Potential impact describes what that observation could mean under the conditions stated.
We recommend marking these three levels separately while reviewing the report. When wording is unclear, ask what was observed directly, what was inferred and which additional check would resolve the outstanding question. This keeps findings useful even when they could not be fully confirmed within the agreed scope.
For authorisation testing, the role, permitted action and affected data boundary would matter. For a DNS configuration, the relevant details would include the actual record, retrieval time and intended function. A screenshot alone does not provide that context.
Understand the evidence needed for roles and access permissions
Add business context to technical ratings
CVSS describes technical severity through documented characteristics; the metrics used and the vector matter to interpretation. EPSS estimates the probability that exploitation of a CVE will be observed within the next 30 days. Neither value alone decides what should happen to a particular system.
Also check applicability, exposure, the importance of the service and existing protective measures. An action may be urgent because a central business process is affected. Conversely, a high score without a matching affected product version does not establish that your system is vulnerable. [2] [3]
Turn each finding into a workable task
For implementation, we recommend a short action record. It can live in your existing ticketing system; another platform is not necessary. Keep enough context for the person making the change to understand the expected outcome without having to guess the original assessment objective.
- Identify the finding reference and affected system.
- Assign an owner or responsible service provider.
- Describe the specific change and any temporary measure.
- Choose a deadline using the risk and operational dependencies.
- Record what evidence will demonstrate that the change worked.
- Document the reason and review date for a deferred or rejected action.
Distinguish completed work from verified remediation
A closed ticket initially shows that a work item has ended. Establishing that the relevant security property is now satisfied needs suitable evidence. Decide during change planning which condition will be checked again and who will accept the result.
NIST includes the development of mitigation measures in the assessment process. For your own follow-up, we recommend separate states such as planned, implemented, retested and still open. A change without a retest will then not be passed on accidentally as a verified resolution.
Keep the report version and its actions together. When the system changes later, you can identify which version an earlier conclusion applied to. Management usually needs a short view of unresolved decisions, owners and next dates; the detailed technical evidence remains attached to the finding. [4]
Related reading
Sources & further reading
Primary sources checked on 05.10.2026.
Sources and limitations are identified in the article.