Security Vulnerability Management

Trigger Boundary

• •Use when security controls, abuse paths, or compliance obligations must be defined.
• •Do not use for non-security product prioritization; use requirement or roadmap skills.
• •Do not use for purely aesthetic UI decisions.

Goal

Reduce exploitable risk with verifiable security controls.

Inputs

• •Change scope and risk profile
• •Domain evidence for vulnerability intake, prioritization, remediation, and verification
• •Operational, compliance, and rollout constraints

Outputs

• •Vulnerability triage and remediation backlog
• •Decision log for vulnerability intake, prioritization, remediation, and verification
• •Verification checklist with measurable pass-fail criteria

Workflow

1. •Clarify outcomes and hard constraints for vulnerability intake, prioritization, remediation, and verification.
2. •Produce options and select an approach for vulnerability intake, prioritization, remediation, and verification.
3. •Evaluate trade-offs across security, performance, operability, and maintainability.
4. •Verify decisions using SLA conformance and fix verification evidence.
5. •Publish decisions, residual risks, and accountable follow-up actions.

Quality Gates

• •Scope and assumptions for vulnerability intake, prioritization, remediation, and verification are explicit and reviewable.
• •Decision rationale is backed by evidence instead of preference.
• •Rollout and rollback criteria are defined when production impact exists.
• •Residual risks have owners, due dates, and verification steps.

Failure Handling

• •Stop when critical vulnerabilities exceed remediation SLA without mitigation.
• •Escalate when accepted risk exceeds team policy thresholds.