Who should be accountable for software attestation evidence and why?

Why accountability should sit with a named certifying executive

A software attestation only has value if someone with organisational authority owns the assertion. A named certifying executive provides that accountability, while engineering, security, and compliance supply the evidence needed to support it. This separation prevents the attestation from becoming a team-level opinion and keeps responsibility aligned to enterprise control integrity.

The practical reason is that attestation is not a narrow technical checklist. It is a statement about how the organisation controls software provenance, change discipline, and risk acceptance. The accountable executive must be able to stand behind the claim, but the claim itself should be grounded in operational evidence from the teams that build, secure, and govern the software.

What evidence should support the certification

Evidence should come from the functions that actually observe the control environment. Engineering can show build and release integrity, security can validate control coverage and exceptions, and compliance can confirm policy alignment and retained records. When those inputs are combined, the certifying executive is deciding on a substantiated control posture, not signing off on an unverified summary.

This matters because attestation evidence is only credible when it is reproducible and reviewable. Teams should be able to trace the assertion back to source systems, approval records, and measurable control outcomes. If the evidence cannot be reassembled during audit, incident review, or regulatory challenge, the attestation is too weak to rely on.

For software supply-chain assurance, a useful reference point is SLSA, because it frames provenance and integrity as properties that must be demonstrated, not merely claimed. That is the same logic that makes certification a leadership responsibility supported by operational evidence.

How to structure ownership without losing control integrity

The strongest operating model is one accountable signer, multiple evidence owners. The executive owns the final declaration and escalation path; engineering owns the facts about the pipeline and release process; security owns control testing and exception handling; compliance owns policy traceability and retention. That structure keeps the attestation authoritative without turning it into a single-team artifact.

In practice, this works best when the organisation can answer three questions quickly: who signed, what evidence supported the signature, and what changed since the last attestation. If any of those answers are unclear, the control is drifting from certification into ceremony. The review process should therefore be designed to surface exceptions, not just confirm that a form was completed.

External control frameworks reinforce that model. NIST SP 800-53 Rev. 5 Security and Privacy Controls supports accountable control ownership and evidence retention, while NIST Cybersecurity Framework 2.0 reinforces governance as an executive function rather than a purely technical one.

Practitioner Guidance

What to verify: The certifying executive should be able to identify the evidence sources, the control exceptions, and the approval path without relying on a single team’s summary. If the evidence is not independently reviewable, the attestation is not mature enough to sign.

What good looks like: One accountable signer, clear evidence lineage, and explicit ownership across engineering, security, and compliance. The organisation should be able to show not only that the attestation was signed, but why it was reasonable to sign it.

Decision rule: If the statement concerns enterprise-wide control integrity, route accountability to an executive owner and treat the contributing teams as evidence providers. If the statement is only a local technical claim, keep it at the operational layer.

Practitioner takeaway: Attestation fails when it is treated as a documentation task; it works when executive accountability and multi-team evidence are both mandatory parts of the same control.

Related resources from NHI Mgmt Group

• Who is accountable when software vulnerability evidence is incomplete during CRA readiness efforts?
• Who is accountable when a release ships with incomplete software supply chain evidence?
• Who is accountable for AppSec attestation and security posture reporting when regulators and boards demand evidence?
• Who is accountable for providing exploitability evidence to customers and regulators when a product ships software vulnerabilities?