Occasionally, despite defining SLAs to certain 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 mostly 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 to be 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. On a practical level, this means that a day in either direction shouldn’t affect the meaning behind the SLA definitions.
Some customers have global operations, and discussing a specific timezone just 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 an SLA of no more than 30 days.
For further information on defining SLAs, visit our Settings article.
Different tools might have different timezone settings, which could affect SLA definitions between organizations or even between business units within the same organization.
A ±1 day discrepancy with your SLAs is totally normal and occurs due to timezone differences.
However, if the discrepancy is larger than one day, please reach out to us, as this should not occur.