Skip to main content
SLA Policies

Define your global SLA and create new SLA policies

Updated over a week ago

What is the purpose of the SLA in the Vulcan Platform?

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:

SLA per Business Group - Why do you need it?

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:

  • Define SLAs for the different development environments. For example, a strict SLA for production environments vs. a more lenient SLA for non-production environments.

  • Define SLAs for the different business units in the organization—for example, Front-End and DevOps.

  • Define SLA to meet the security regulation of an asset. For example, HIPAA or PCI assets vs. no-regulation required assets.

  • Define SLA per a Security Scanner (Connector)—for example, an SLA for all the vulnerabilities identified by Acunetix 360.

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

Managing SLA

To access SLA Policies, Go to Settings > SLA.

This is where you can:

  • Define your global SLA and create new SLA Policies.

  • Set a time frame for each SLA (in days); use 0 days to turn SLA tracking off.

  • Prioritize SLA policies using the up and down arrows. In case of a conflict, the topmost policy will be applied.

The Global SLA Policy (default)

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.

Managing SLA Per Business Group

Create a new SLA policy

  1. Go to Settings > SLA tab > Create New SLA Policy button

  2. Fill in the required details:

    • SLA Policy name

    • Time frame in days for each severity level

  3. Click the dropdown to assign Business Groups to the policy

  4. Click Save

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.

SLA prioritization

How it works

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".

Change the precedence/priority of an SLA

  1. Go to Settings > SLA

  2. Change the precedence of one SLA over the by using the Up and Down arrows:

Assign an SLA Policy to a Business Group

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

Assign/unassign a Business Group to an SLA through the main SLA Management page

  1. Go to Settings > SLA tab

  2. Click the pen symbol to edit an existing SLA policy

  3. Assign a Business Group to the SLA Policy

  4. Click Save

Assign/Unassign a Business Group to an SLA Policy through the Business Group setup page

  1. Go to Settings > Business Groups

  2. Select a Business Group

  3. Assign/Unassign the Business Group to an SLA Policy

Edit an SLA Policy

To edit an SLA policy:

  1. Go to Settings > SLA tab.

  2. Click the respective Edit pen symbol to edit.

  3. Make your changes.

  4. Click Save.

Delete an SLA Policy

To delete an SLA policy:

  1. Go to Settings > SLA tab.

  2. Click the respective Trash symbol to delete.

  3. Read the confirmation message to ensure you are aware of any relevant impact.

  4. Click Delete to confirm.


FAQ

What if I have an asset that isn't associated with a specific Business Group?

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").

What if I have a Business Group that isn't associated with an 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").

How do I check the SLA Policy of an asset?

To check what SLA Policy an asset is assigned to:

  1. Go to Assets

  2. Click on an asset from the list

  3. Go to the Details tab

  4. Review the SLA Policy assigned (if available)

What happens if I insert the number 0 for an SLA?

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

Can I assign a Business Group to more than one SLA?

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

What if the severity level of a vulnerability changes? What happens to its SLA?

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.

How long does it take for an SLA change to take effect?

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.

How does the Timezone affect the SLA?

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:

  • Most customers work in weekly/monthly/quarterly SLA definitions. Practically, a day in either direction shouldn’t affect the meaning behind the SLA definitions.

  • Some customers have global operations, and discussing a specific timezone wouldn’t make sense.

  • Vulcan users can always manually reduce/increase the SLA within Vulcan to present a more conservative approach. For example, customers located west of the UTC line could define SLAs of 29 days instead of 30 days, thus making the discrepancy reach 30 days at most.
    For further information on defining SLAs, visit our Settings article.

  • Different tools might have different timezone settings, affecting SLA definitions between organizations or business units within the same organization.

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.

Did this answer your question?