The SLA feature in the Vulcan Platform lets you define the number of days for a Critical/High/Medium/Low vulnerability to be considered as "Exceeding". This means that starting from the day a vulnerability is discovered, the SLA of that vulnerability starts a countdown. For example, if you define 6 days SLA for Critical severity vulnerabilities, it means that from the day a Critical vulnerability is found, the expected SLA for the fix is 6 days max. When passing the 6th day, the Vulnerability SLA changes its status to "Exceeded" or "Exceeding" - Which should tell you that you have a Critical Vulnerability that hasn't been fixed for more than six days (and we don't want that - do we?).

To learn more about how risks are defined and risk calculation, see:

The SLA per Business Group feature lets define different SLAs for severity level (High, Medium, etc.,) and per a Business Group.

Once you create your Business Groups, you can easily assign different SLAs for the other Business Groups, or simply assign several Business Groups to the same SLA.

This capability is extremely useful in the following example cases:

In other words, you can define an SLA for any division that has a defined Business Group.

To access SLA Policies, Go to Settings > SLA.

This is where you can:

In the SLA view, the first line is the Global SLA Policy (the same one you had). This means that your current SLA configurations haven't changed. The starting point of this feature is having all Business Groups assigned to the Default Global SLA Policy.

Later on, once you create your SLA Policies, you'll get to assign business groups to your own SLA policies. A Business Group assigned to an SLA policy of your own is automatically removed from the Global SLA Policy.

The Global SLA Policy is a fixed policy that cannot be removed or renamed. The only thing you can change about it is the SLA days.

Note: You can always return the SLA to default by clicking the "Return to default" button.

Note: For the changes to take effect, it can take several minutes up to several hours, depending on the size of the environment. The larger the environment, the longer it takes.

Note: Each Business Group can be assigned only to ONE SLA Policy. If you see a grayed-out business group, it means that this business group is assigned to a different SLA Policy. To re-assign the Business Group, you need to unassign it first.

To explain the importance of the SLA policies order, let's take the following scenario:

Imagine you have an asset that belongs to two different Business Groups: Finance and Marketing. Finance is associated with the SLA Policy "Acunetix 360", while Marketing is related to the SLA Policy "Production".

Now you ask, what SLA does this asset have?

It depends on the SLA Policies order.

The policy that is placed higher on the list is the policy that determines the SLA for the associated asset. For example, suppose we have vulnerabilities on an asset that belongs to two different business groups, each with a different assigned SLA policy. In that case, the policy on top of the list is the one that determines the SLA of the vulnerabilities. In this case, if the policy "Acunetix 360" is placed above "Production", the "Acunetix 360" SLA policy takes precedence over "Production".

There are two ways to assign an SLA Policy to a Business Group:

To edit an SLA policy:

To delete an SLA policy:

If you have vulnerabilities on an asset that isn't associated with a business group, those vulnerabilities automatically get the default SLA policy ("Global SLA Policy").

If you have a business group that isn't associated with a specific SLA Policy, it automatically gets the default SLA policy ("Global SLA Policy").

To check what SLA Policy an asset is assigned to:

The number 0 means there is no SLA for this level of Severity. Meaning it turns the SLA tracking off.

No. Each business group can be assigned to only one SLA policy.

It depends on the environment's configuration.
Option 1: The SLA won't change if the priority/severity changes.
Option 2: The SLA clock automatically restarts when the status changes.

To configure the SLA behavior upon status change, contact your CSM at Vulcan.

It can take several minutes up to several hours for the SLA change to take effect on all vulnerability instances and relevant charts. Therefore, we recommend you allow up to 24 hours for the change to be implemented entirely.

If, after 24 hours, the change isn't in effect, reach out to your customer success manager or customer support.

Occasionally, despite defining SLAs to specific values, some vulnerabilities show an SLA that is ±1 day (not more!) from those targets.

This happens because the Vulcan platform is UTC (AKA GMT)-based. This means that for most of our customers, there will be an inherent time difference between their business and the Vulcan platform.

These time differences go unnoticed, but sometimes they can cause an SLA discrepancy.

For example, if Vulcan identified a medium vulnerability (SLA of 90 days, for instance) at 1:00 AM UTC on January 2nd, 2021, the SLA date will be defined as April 2nd, 2021.
However, from an EST customer’s standpoint, the vulnerability was identified at 8:00 or 9:00 PM (depending on daylight saving time) on January 1st, so the SLA date should have been April 1st.
In this example, the customer will see an SLA date 91 days ahead instead of 90.

This is the desired behavior for several reasons:

Conclusion:

A ±1 day discrepancy with your SLAs is normal due to timezone differences.
However, if the discrepancy is more significant than one day, please contact us, as this should not occur.