Vulnerability Remediation Workflow

Why should we automate vulnerability remediation instead of tracking it manually in spreadsheets or email?

Manual tracking of vulnerability reports across email and spreadsheets makes it easy to lose track of due dates, owner responses and reporter updates. This workflow assigns a due date automatically based on reported severity, routes each report through validation and owner response, and keeps a full timeline of what happened on each record. That reduces the administrative overhead of chasing status updates and helps the team see where every report stands at a glance.

What is the ROI of using this workflow compared to handling vulnerability reports case by case?

Each report is registered as a record with a reference number, status and timeline the moment it's submitted, removing the need to set up tracking manually for every case. Severity-based due dates, automatic reporter acknowledgements and structured routing between validation, remediation and verification reduce the time security staff spend on coordination. Over many reports, this can meaningfully cut the manual effort needed to move each one from intake to closure.

How is the remediation due date determined, and can it be adjusted?

The workflow routes each validated report based on its reported severity, setting the due date to 7 days for Critical, 14 days for High, 30 days for Medium, and 90 days for Low. These rules can be changed by describing the change in plain English or editing the routing step in the workflow editor, and earlier versions of the workflow are kept. This means the due date logic can be tailored to a workspace's own remediation targets without a development project.

Who is responsible for validating a reported vulnerability, and what happens if it's a false positive?

The security team validates whether the reported vulnerability is genuine, recording a Validation Result and Notes on the record before the workflow continues. If the result is marked as a false positive, the record status is set to Closed - False Positive and the reporter is emailed to let them know. If it's valid, the record moves to the asset owner for a response.

What choices does the asset owner have when responding to a validated vulnerability?

Once a report is validated, the status is set to Assigned and the asset owner is asked to choose between remediating the issue or accepting the risk, recording their Response and a Remediation Plan or Risk Justification. Choosing to remediate moves the record toward applying and verifying a fix, while choosing to accept the risk sends the justification to a security manager for approval. This gives asset owners a documented, single point of decision for each vulnerability.

What happens if the security manager rejects a risk acceptance request?

If the security manager rejects the risk acceptance justification, the workflow returns to the asset owner's response task so they can submit a revised justification or choose to remediate instead. If approved, the record status is set to Risk Accepted and the reporter is emailed to confirm the outcome. This loop keeps risk acceptance decisions tied to manager sign-off before a record can move to that status.

How does fix verification work, and what if the first fix doesn't resolve the issue?

After the asset owner applies a fix and records Fix Applied details and Test Evidence, the status is set to Remediating and the security team verifies whether the fix resolved the vulnerability, recording a Verification Result and Notes. If the result is marked as fixed, the record status is set to Closed and the reporter is emailed to confirm closure. If not fixed, the workflow returns to the asset owner's fix task so a further fix can be applied and re-verified.

When is the reporter kept informed, and what do they see?

Reporters take part through the public request form and receive emails at key milestones without needing an account: an acknowledgement with their reference number on submission, a false positive notice if the report doesn't validate, a risk accepted notice if that path is approved, and a fixed notice on closure. This keeps reporters informed of progress without requiring them to log in or chase status updates.

Can this workflow be adapted to different severity levels, approval steps or task assignments?

Yes. A workspace can change the workflow by describing the change in plain English or by editing steps directly in the workflow editor, and earlier versions are retained. This makes it possible to adjust severity routing, due date rules, or which team members are assigned validation, response and verification tasks, without a separate development project.

What visibility does the security team have into vulnerabilities across the workspace?

Each vulnerability is a record with a reference number, status and timeline, and table views and dashboards show records grouped by status such as Reported, Assigned, Remediating, Risk Accepted or Closed. Workspace activity is logged, so the team can review progress across all reported vulnerabilities in one place. Businesses should confirm this level of record-keeping meets their own compliance or audit requirements.