Skip to main content

Verification & SLAs

Verification ensures that vulnerabilities are actually remediated, not just marked as done in a ticket. SLAs define how quickly issues must be fixed based on risk.

Use this guide to verify remediation through rescans, track SLAs, and support evidence collection and reporting in Cloudaware.

Verification by Rescan​

Typical pattern:

  1. A patch or configuration change is implemented (often via Patch Management or change workflows).
  2. A verification scan runs (scheduled or on‑demand).
  3. Cloudaware updates Cloudaware Vulnerability Scan records:
    • The date/time value is set for Deleted From Scanner (CA10__disappearanceTime__c) when the issue is no longer detected.
    • Status changes to Remediated/Closed.
  4. Related tasks and tickets may be updated or closed.

If the vulnerability reappears on subsequent scans, a new finding can be created or the status re‑opened, depending on your workflow.

SLA Definitions​

SLA targets are usually defined by risk band, for example:

  • Critical – fix within 7–14 days.
  • High – fix within 30 days.
  • Medium – fix within 60–90 days.
  • Low – fix as capacity allows or within a longer horizon.

Cloudaware stores due dates and SLA status on Remediation Tasks or related objects, using:

  • Risk band or severity.
  • Environment (production vs non‑production).
  • Regulatory scope (e.g., PCI, HIPAA).

See Exceptions & SLAs for exception policies and SLA tracking.

Evidence and Audit Trail​

For regulated environments:

  • Capture notes or attachments showing what change was implemented.
  • Retain links to change records, patch jobs, and CMDB snapshots.
  • Use dashboards and reports to demonstrate:
    • SLA adherence.
    • Trends in time‑to‑remediate by OU or application.

Verification and SLA data feed executive dashboards as well as detailed escalation reports by OU. See Dashboards & Reporting.