The remediation workflow is the execution path inside the broader vulnerability-management system. Its purpose is to make sure a confirmed security issue does not remain indefinitely between triage, engineering, testing and release teams without ownership, evidence or a clear closure decision.
Start the Remediation Workflow After Technical Confirmation
A remediation workflow should begin when a vulnerability has been confirmed or when the available evidence is strong enough to require treatment while investigation continues. The vulnerability case should already preserve the original report, validation evidence and preliminary affected-product information. The workflow then moves the issue from investigation into owned corrective action rather than leaving it indefinitely in triage.
- Confirm or substantiate the vulnerability.
- Preserve validation evidence.
- Create remediation ownership.
- Move the issue into corrective action.
Step 1: Confirm Affected Versions
Before engineering starts a fix, the team should identify affected versions, supported branches and relevant third-party components. This determines which users are exposed and which release branches need corrective work. The affected-version record should remain updateable because investigation can reveal additional branches or prove that an initially suspected version is not affected.
- Affected product versions.
- Supported branches.
- Affected components.
- Confirmed unaffected versions where useful.
Step 2: Assess Severity and Product Risk
The vulnerability should be assessed for security impact, exploitability, exposure, attack prerequisites, affected assets and relevant compensating controls. Annex I Part II point 2 requires remediation without delay in relation to the risks posed to the product, so the risk assessment should translate into operational urgency rather than remain an isolated score.
- Assess impact.
- Assess exploitability.
- Assess exposure.
- Assess compensating controls.
- Record residual risk.
Step 3: Run the Article 14 Decision Separately
The technical remediation workflow and Article 14 regulatory reporting should be connected but separate. If evidence indicates that the vulnerability is actively exploited, the manufacturer should assess the Article 14 trigger and preserve the awareness timeline. Regulatory notification should not wait for the security fix to be completed, and technical remediation should not stop while reporting is prepared.
- Assess active exploitation.
- Preserve awareness time.
- Escalate qualifying regulatory reporting.
- Continue remediation in parallel.
Step 4: Assign a Remediation Owner
Every confirmed vulnerability requiring action should have a remediation owner. Ownership may sit with a product engineering team, firmware team, platform team or supplier-management function depending on the root cause. The owner should be responsible for progressing the correction and coordinating dependencies rather than merely receiving notification that the vulnerability exists.
- Name the remediation owner.
- Identify dependent teams.
- Define expected corrective action.
- Escalate stalled remediation.
Step 5: Use Mitigation When Immediate Permanent Remediation Is Not Available
High-risk vulnerabilities can require action before a permanent security update is ready. A validated mitigation can reduce exposure by disabling a vulnerable feature, restricting access or changing configuration. The workflow should record mitigation separately from remediation so temporary risk reduction is not mistaken for elimination of the vulnerable condition.
- Identify temporary mitigation.
- Verify effectiveness.
- Communicate necessary user action.
- Continue permanent remediation.
Step 6: Develop the Permanent Fix
Annex I Part II point 2 requires vulnerabilities to be addressed and remediated without delay in relation to the risks posed. Engineering should therefore develop the permanent correction with a clear connection to the vulnerability record. Depending on the product, remediation can involve code changes, firmware changes, configuration changes, dependency upgrades, backports or replacement of an unsupported component.
- Link engineering work to the vulnerability case.
- Identify corrected branches.
- Control security-sensitive changes.
- Keep remediation scope clear.
Step 7: Verify the Fix
Annex I Part II point 3 requires effective and regular tests and reviews of product security. The remediation workflow should retest the original vulnerable condition and check important bypass or regression paths before release. Each supported branch receiving a different backport or implementation should be verified in its own relevant environment rather than assuming that testing on the newest version proves every older branch is fixed.
- Retest the vulnerability.
- Check important bypasses.
- Run security regression tests.
- Verify branch-specific fixes.
Step 8: Prepare and Release the Security Update
Where remediation requires a security update, the corrected build should move through the secure update-release process. The manufacturer should protect update authenticity and integrity, identify the correct affected versions and avoid unnecessary delay once the security update is available. Where technically feasible, security updates should be separated from unrelated functionality updates.
- Create the corrected build.
- Verify update authenticity and integrity.
- Target affected versions.
- Release the security update.
Step 9: Communicate Fixed Vulnerabilities
Once the security update has been made available, Annex I Part II point 4 requires information about fixed vulnerabilities to be shared and publicly disclosed, subject to its justified disclosure-delay provision. Point 8 also requires security updates to be accompanied by advisory messages containing relevant information including potential action users should take. Communication should use the same affected-version and fixed-version records used by engineering.
- Publish the security advisory.
- Identify affected versions.
- Identify fixed versions.
- Explain customer action.
Step 10: Confirm Rollout and Availability
The workflow should distinguish a fix that exists internally from an update actually available to users. Release evidence should identify publication date, package or build identifier and distribution status. Where rollout can be observed, the manufacturer can also monitor deployment progress for serious vulnerabilities, while recognising that customer-controlled installations may prevent complete visibility.
- Confirm update availability.
- Record publication date.
- Record package or build identifier.
- Track rollout where practical.
Step 11: Apply Closure Criteria
A vulnerability case should have explicit closure criteria. Closure can require confirmation that affected supported versions have been remediated or otherwise appropriately treated, verification is complete, required security updates are available, customer communication has been published and Article 14 obligations have been addressed where applicable. A vulnerability should not close merely because the engineering change was merged.
- Remediation complete.
- Verification complete.
- Security update available.
- Communication complete.
- Regulatory reporting complete where applicable.
Step 12: Feed the Root Cause Back Into Development
Closure should include a decision about whether the vulnerability reveals a broader development weakness. Repeated authentication failures can indicate missing security requirements, repeated dependency problems can indicate weak component governance and repeated parser defects can indicate insufficient adversarial testing. Corrective lessons should feed into architecture, coding standards, testing and release controls so the same vulnerability class is less likely to recur.
- Identify root cause.
- Update engineering controls.
- Create regression coverage.
- Review repeated vulnerability patterns.
Keep One Evidence Chain From Confirmation to Closure
The completed case should provide an evidence chain covering affected versions, severity, remediation priority, Article 14 assessment, remediation owner, mitigation, fix, verification, security-update release, fixed-vulnerability communication and closure decision. This makes the workflow reviewable and helps demonstrate that the manufacturer handled vulnerabilities effectively rather than relying on disconnected tickets across several teams.
- Affected-version evidence.
- Priority rationale.
- Remediation owner.
- Test evidence.
- Security-update identifier.
- Security advisory.
- Closure decision.
Official sources
Read the full legal text and Commission material for precise wording, qualifications and updates.