NOTE: These guidelines are outdated and to be replaced with a contextual severity assessment scoring system. In the transition phase, the guidelines below will still be effective, unless explicitly mentioned in the program description.

As a general rule of thumb, severity assessments will be based upon their respective CVSS v3 score, with the factors below taken into account to raise or lower the final severity score:

Volume - how much data is affected?

  • Low: a small amount of total (accounts) are affected

  • Medium: significant amount of total (accounts) are affected

  • High all (accounts) are affected

Privileges required - how many privileges are required?

  • None: no privileges are required (unauth, self sign up)

  • Low: low privileges are required (e.g. employee user)

  • High: high privileges are required (e.g. admin user)

User interaction How many user interaction is required?

  • None: no user interaction required

  • Limited: user interaction is likely

  • Complex: user interaction is unlikely

Scope How much privileges are obtained?

  • Unchanged: no higher privileges are obtained

  • Changed: significant higher privileges are obtained

Confidentiality How confidential is the exposed data?

  • None: no internal data is exposed

  • Low:  some internal data is exposed

  • High: significant internal data is exposed

Integrity How much damage can be done?

  • None: no data can be modified

  • Low: some significant data can be modified

  • High: all significant data can be modified

Reliability How likely is an attack?

  • Low: a successful attack is unlikely (Edge only)

  • Medium: a successful attack is doable (social engineering)

  • High: a successful attack will work in all to most cases

Business impact Does this affect the core business?

  • Low: the affected data is unrelated to the core business

  • High: the affected data is related to the core business

Example severities

This table provides an incomplete overview of severity estimates according to their bug type. All records are indicative and the metrics above will determine the final severity score.


  • A remote code execution vulnerability on the production server


  • A SQL vulnerability exposing all customer records

  • A numeric IDOR that allows mass write/read actions on critical features 

  • Path traversal leading to the disclosure of local files


  • A limited IDOR exposing sensitive data

  • A stored XSS vulnerability in highly exposed areas


  • A DOM XSS vulnerability

  • An IDOR leading to disclosure of non-critical data

  • A CSRF with a significant impact (e.g. changing e-mails)


  • A reflected XSS vulnerability that requires significant user interaction

  • A CSRF vulnerability in a non-critical feature

This is intigriti's recommended severity standard and may be updated on a regular basis. Programs are free to set up their own severity structure. Please refer to the program description for the severity assessment methodology that applies to it.

Did this answer your question?