Mapping CVSS to Jira priority without an argument.

The most reliable signal of a healthy VAPT programme is that nobody argues about priority in the ticket. That is not because arguments have been suppressed — it is because severity stopped being a judgement call.

Declared severity vs derived severity

A declared severity is a human saying a number. A derived severity is a function of the asset, the vector and the environment. The second one is auditable, reproducible, and identical for everyone who looks at it, which is precisely what you need when a director and a developer disagree.

severity  = f(cvss_vector, asset_criticality, exposure)

criticality  production customer data   → 1.0
             internal tooling           → 0.7
             sandbox / staging          → 0.4
exposure     internet-facing, no auth  → 1.0
             authenticated only         → 0.6
             internal network           → 0.3

priority = Critical if severity >= 9.0 and exposure == 1.0
           P1        if severity >= 7.0
           P2        if severity >= 4.0
           P4        otherwise

The output is deterministic, so the argument moves from the number to the inputs — and the inputs are facts somebody in the room can confirm.

Then sync it, in both directions

Mapping severity to priority is the easy half. The half that matters operationally is the return path: when an engineer moves a ticket to Done, the finding moves with it, and when a retest verifies the fix, the ticket resolves with evidence attached. Without the return path you are one direction from a system that quietly rots.

• Outbound: finding → issue, severity → priority, asset → component, CVSS → custom field.
• Inbound: status, assignee and comments flow back into the finding's history.
• Resolution: a verified retest closes the issue rather than requiring someone to remember.
• Escalation: an SLA breach on the Jira ticket escalates the finding, not just the ticket.