Severity and priority answer two separate questions: how badly a defect affects a system, and how urgently the team fixes it. The ISTQB Foundation syllabus lists both as separate fields of a defect report, and the two values can sit far apart. For a rare crash, Microsoft suggests “Severity = 2 - High” with only Priority 3 (Microsoft Learn, 2026). Mozilla, Azure DevOps and Jira each use their own scales. For how classification fits into the full process, see the guide to defect management in software testing.

TL;DR: Severity describes a defect's impact, priority the order in which it gets fixed. Both go into the defect report, and bug triage sets priority against agreed criteria such as release date and risk. For a rare crash triggered by a remote link, Microsoft suggests Severity 2 - High with Priority 3: serious, but not urgent.

Figure 1: Severity describes impact, priority the order of fixing

What is the difference between severity and priority?

Severity is a defect report attribute that describes a defect's impact; priority sets the defect's importance and with it the order of fixing. For the first, the official ISTQB glossary gives “The degree of impact that a defect has on the development, testing or operation of a component or system” (ISTQB Glossary, 2026). The scope covers development, testing and operation.

For priority, the glossary now uses open wording: “The level of importance assigned to a task according to specific criteria” (ISTQB Glossary, 2026). The unofficial mirror istqb-glossary.page and AI answers such as ChatGPT's still quote an older version that speaks of “(business) importance” and names a defect as the example. The current definition talks about tasks and about defined criteria.

That has a practical consequence: whoever assigns priorities has to write the criteria down. Typical criteria are the release date, the number of affected users, customer commitments and regulatory deadlines. Without that list, priority gets negotiated in the meeting, and the loudest voice wins.

The ISTQB Foundation syllabus 4.0.1 lists both values side by side in the defect report: “severity (degree of impact) on the interests of stakeholders or requirements” and “priority to fix” (ISTQB CTFL Syllabus, 2024). The first describes the defect, the second a decision about work.

Severity vs priority: side-by-side comparison

The two fields differ on four points: who sets them, which question they answer, when they change and which scales are common. The table sums this up, with evidence from Mozilla's and Microsoft's documentation.

Eclipse's 7 severity levels were hard to tell apart. Herraiz, German, González-Barahona and Robles grouped the bugs by time to close and found fewer distinct clusters than levels, so they proposed a simpler bug report form (Herraiz et al., MSR, 2008).

For your own scale, that argues for a few clearly described levels. Mozilla and Azure DevOps each get by with 4. Each level needs an example from your own product.

What does the severity and priority 2×2 matrix look like?

The 2×2 matrix combines high and low severity with high and low priority, which gives four cases that bug triage handles differently. Microsoft documents the “severe but not urgent” case with a rare remote link that crashes an application (Microsoft Learn, 2026).

Figure 2: The severity and priority 2×2 matrix (banking examples for illustration)

The banking examples in the table are illustrations, not documented cases. They show how the logic can play out at a financial institution.

The matrix itself is an industry convention, not a standard. Its value lies in the discussion: if a team can't place a defect in one quadrant, it usually lacks facts about the impact, or the priority criteria were never written down.

Which scales do Mozilla, Azure DevOps, Jira and CVSS use?

Mozilla and Azure DevOps each use 4 severity levels, and documented priority scales range from 3 levels (Azure DevOps) to 5 levels (Mozilla, Jira). The same number can mean different things: “P3” at Mozilla means backlog, “Priority 3” in Azure DevOps means the fix is optional.

Figure 3: Severity scales at Mozilla, Azure DevOps and CVSS 4.0

Mozilla (Bugzilla)

Mozilla describes its current levels in its field guide (Mozilla Wiki, 2026):

• S1 (Catastrophic): blocks development or testing, may affect more than 25% of users, data loss, no workaround

• S2 (Serious): major functionality severely impaired, no satisfactory workaround

• S3 (Normal): blocks non-critical functionality, or a workaround exists

• S4 (Small/Trivial): minor significance, cosmetic issues, little or no user impact

For priority, P1 means the current release cycle, P2 the next cycle or the one after, P3 the backlog. P5 means “Will not fix, but will accept a patch”.

Azure DevOps

Microsoft documents 4 severity values for bugs: 1 - Critical (must fix, no acceptable alternative), 2 - High (same impact, an acceptable alternative exists), 3 - Medium (default; incorrect, incomplete or inconsistent results) and 4 - Low (minor or cosmetic defect). Priority has 3 documented levels: 1 must be resolved before shipping and addressed soon, 2 must be resolved before shipping, 3 is optional (Microsoft Learn, 2026).

Jira

Jira ships with 5 default priorities: Highest, High, Medium, Low and Lowest. Admins can change them per project (Atlassian Support, 2026). How a team records severity in Jira depends on its configuration.

CVSS

CVSS rates the severity of a security vulnerability, not the urgency of fixing it. Version 4.0 was published on 1 November 2023 and scores from 0.0 to 10.0, with the optional ratings None (0.0), Low (0.1–3.9), Medium (4.0–6.9), High (7.0–8.9) and Critical (9.0–10.0) (FIRST, 2024). When a team patches a 7.5 depends on context, such as whether the system is reachable from the internet.

Who decides severity and priority in bug triage?

In bug triage, a fixed group sets priority and confirms or corrects severity. Microsoft states: “Typically, the project owner runs the bug triage meetings” (Microsoft Learn, 2026). Team leads, business analysts and other stakeholders attend.

Figure 4: A bug triage meeting in 5 steps

Mozilla defines the roles in more detail. Triagers may override the reporter's value; QA sets an initial value for bugs it files. The rule reads: “Changing a bug's severity requires a comment explaining the rationale” (Mozilla Firefox Source Docs, 2026). Priority is optional for triagers.

A triage meeting can run in 5 steps:

1. Review new reports and filter out anything that isn't a defect. The ISTQB syllabus names false-positive results and change requests as possible outcomes (ISTQB CTFL Syllabus, 2024).

2. Check reproducibility and request missing details. The article on writing a complete bug report lists what belongs in one.

3. Confirm or change severity, with a written reason for every change.

4. Set priority against the written criteria: release date, affected customers, risk, regulatory deadlines.

5. Assign an owner and target release, and start a root cause analysis for severe cases.

Report fields often change after filing. Xia, Lo, Wen, Shihab and Zhou analyzed 190,558 bug reports from 4 open-source projects: about 80% had at least one field reassigned, and those bugs took longer to fix (Xia et al. 2014, summarised in Xia et al. 2016). The figure covers all fields combined, not severity alone.

What does DORA require for ICT incident classification?

DORA requires EU financial entities to classify ICT-related incidents by priority and severity. Article 17(3)(b) of Regulation (EU) 2022/2554 calls for procedures to classify incidents “according to their priority and severity and according to the criticality of the services impacted” (EUR-Lex, 2022). The regulation has applied since 17 January 2025.

The rule covers incidents in operation, not defect reports from testing. A software defect becomes relevant once it causes an ICT-related incident. Article 17(2) then requires that root causes “are identified, documented and addressed”. DORA doesn't prescribe a bug tracker or a defect report format.

DORA reaches Swiss banks only through EU business or EU subsidiaries. For them, FINMA Circular 2023/1 governs the management of operational risks, including ICT risks. Teams that already keep two separate fields in testing can reuse the same logic in their incident process. The regulatory context is covered in the article on test automation in regulated banks.

What does test automation contribute to classification?

Test automation gives bug triage reproducible evidence for both decisions. Autemos is AI-assisted software for functional test automation across web, mobile, API and desktop. Autemos is not a defect tracker. It doesn't replace Jira or Azure DevOps, and doesn't decide severity or priority.

What an automated test run gives triage:

• Reproducibility: The visual test workflow is the step sequence. Exported Playwright or Appium code reruns outside Autemos.

• Results in Jira: Test executions sync both ways with Jira/Xray, so triage finds the results in Jira (Jira/Xray integration).

• Clear separation: Every self-healing action appears in the report and can be reviewed, rejected or rolled back. A changed locator shows up as a change to the test and doesn't reach triage as a supposed product defect.

• Environment: Per-environment configuration (DEV, TEST, STAGING, PROD) records where the failure happened, which matters for judging customer impact.

Both values take effect in the pipeline once quality gates use them as criteria, for example: no release as long as an S1 (Mozilla) or 1 - Critical (Azure DevOps) defect is open. After a hotfix for a high-priority defect, a quick smoke test checks core functions before the team tests more broadly.

Frequently asked questions

Who sets the severity of a bug?

Triage makes the binding call on severity. At Mozilla, QA sets an initial value for bugs it files or reproduces, and other reporters are asked to leave the field at its default. Triagers can override any value, and every change needs a comment with the rationale (Mozilla Firefox Source Docs, 2026).

Can a bug have high severity and low priority?

Yes, Microsoft describes this case. For a rare remote link that crashes an application, Microsoft suggests Severity 2 - High and Priority 3 (Microsoft Learn, 2026). The crash is serious but rare, so other work comes first.

Is a CVSS score the same as priority?

No, a CVSS score measures the severity of a security vulnerability on a scale from 0.0 to 10.0 (FIRST, 2024). Priority comes from context: system exposure, affected data, available workarounds. Two vulnerabilities with the same score can differ in urgency.

How often do severity and priority get changed after filing?

No verified figure exists for severity alone. Xia et al. found in 190,558 bug reports from 4 open-source projects that about 80% had at least one field reassigned (Xia et al. 2014, summarised in Xia et al. 2016). That rate covers all fields combined, component included.

Can AI determine severity automatically?

Partly. Lamkanfi, Demeyer, Giger and Goethals predicted severity with text mining and, with about 500 reports per level, reached precision and recall of 0.65 to 0.75 for Mozilla and Eclipse (Lamkanfi et al., MSR, 2010). Autemos makes no such prediction; the call stays with triage.

Conclusion

Severity and priority belong in every defect report, in separate fields with separate owners. The first describes the impact on development, testing or operation. The second is a decision made against defined criteria, and the team has to write those criteria down.

In practice, that leaves three things to set up:

• A scale with 4 clearly described levels and examples from your own product.

• A fixed bug triage meeting where every severity change gets a written reason.

• Reproducible evidence from the test run, so classification rests on facts.

DORA asks EU financial entities to classify ICT-related incidents by priority and severity, too. If you'd like to see how test results from Autemos flow through Jira/Xray into your triage, talk to our team.