Who should be accountable for VEX determinations in a software programme?

Why This Matters for Security Teams

VEX determinations are only useful when they are treated as security decisions, not as static documentation. The accountable owner needs enough authority to weigh exploitability, compensating controls, product exposure, and release timing, then record a decision that can survive audit and incident review. That is why the control should sit with product security leadership, while engineering and AppSec supply the technical evidence that supports or challenges the decision. NIST’s NIST SP 800-53 Rev 5 Security and Privacy Controls is useful here because it reinforces that accountability, reviewability, and evidence matter as much as the technical assessment itself.

The common mistake is assuming VEX is a vulnerability management task alone. In practice, VEX statements affect whether a finding is triaged, suppressed, escalated, or accepted, so the decision has operational and sometimes contractual impact. If no one is clearly accountable, the organisation tends to produce inconsistent determinations across products or teams, especially when deadlines are tight or multiple releases are moving in parallel. In practice, many security teams encounter VEX as disputed paperwork only after a shipment decision has already been made, rather than through intentional governance.

How It Works in Practice

In a mature programme, accountability follows a simple pattern: one named owner approves the VEX outcome, subject matter experts provide evidence, and release governance ensures the decision is current before publication or shipment. The owner is usually the team responsible for product security decisions, because that function can balance risk acceptance against remediation priority and customer impact. Engineering, AppSec, and supply-chain stakeholders contribute analysis, but they should not dilute the decision point.

A practical workflow usually includes:

• Assigning a single approver for each VEX statement, with a backup approver for absence or escalation.
• Recording the artifact version, product version, advisory source, and timestamp for every decision.
• Linking the VEX determination to the specific affected component, build, or release branch.
• Reviewing the decision again when patch state, exploit intelligence, or deployment context changes.
• Retaining evidence so the rationale can be traced during audit, customer inquiry, or incident response.

This model works best when VEX is embedded in product release governance, not handled as an afterthought in ticket queues. It also aligns with broader software assurance expectations in the NIST control baseline, where accountable approval and documented review are core operational themes. Where organisations also maintain supplier risk or software bill of materials processes, the same owner should coordinate across those workflows so determinations stay consistent. These controls tend to break down when distributed teams ship continuously without a single release authority, because the decision becomes detached from the actual product state.

Common Variations and Edge Cases

Tighter accountability often increases coordination overhead, requiring organisations to balance speed of release against the need for defensible security judgment. That tradeoff is real, especially in fast-moving software programmes where product teams want rapid exception handling and security teams want evidence-based decisions.

Some programmes give the final sign-off to a central AppSec function, while others place it with product security or release management. Current guidance suggests there is no universal standard for this yet, but the accountable role should always be the one that can authorise risk acceptance and compel re-review when conditions change. A shared service team can advise, but shared accountability usually creates ambiguity unless one person is named as final approver.

Edge cases include outsourced development, multi-vendor products, and cloud services where patching may happen outside the release team’s direct control. In those environments, the accountable owner still needs authority over the determination, but the evidence may come from multiple suppliers and internal service owners. If the product is regulated or customer-facing, the decision trail should be even stricter, because a VEX statement may affect incident notifications, procurement assurance, or downstream disclosure. The key test is simple: if the decision cannot be revisited quickly when the threat or patch state changes, the accountability model is too weak for operational use.

Related resources from NHI Mgmt Group

• Who is accountable when an identity governance programme fails?
• Who is accountable when identity controls fail in a GRC programme?
• Who is accountable for cryptographic posture management in a zero trust programme?
• Who is accountable when software licence terms are violated?