Managing Assurance Evidence: A Guide to ISO/IEC 15026‑2‑13:2017

Requirements for Evidence Management in System and Software Assurance Cases

Scope and Purpose

ISO/IEC 15026‑2‑13:2017 is a new part of the ISO/IEC 15026 series on system and software assurance. It focuses on the management of assurance evidence – the documented facts, data, and artefacts used to support an assurance case. While the core part (ISO/IEC 15026‑2:2017) defines the structure and content of an assurance case, this standard adds detailed requirements for how evidence should be identified, collected, maintained, and linked to claims and arguments.

The standard is intended for organizations that develop high‑integrity systems (e.g., in aviation, automotive, medical devices, industrial control) where safety, security, or business criticality demands a rigorous, auditable chain of evidence. It applies throughout the lifecycle from concept to decommissioning, with special emphasis on managing evidence across system changes and updates.

Tip: ISO/IEC 15026‑2‑13:2017 can be used alongside ISO/IEC 15026‑3:2015 (System Integrity Levels) to provide a complete evidence framework for integrity level assignment and justification.

Technical Requirements

Evidence Classification and Traceability

The standard defines a three‐level classification scheme for evidence items:

  • Direct evidence – obtained from testing, analysis, or formal verification of the system itself.
  • Indirect evidence – derived from process compliance, development standards, or historical data.
  • Supporting evidence – contextual information such as tool qualifications, personnel competence, or environmental assumptions.

Each evidence item must be uniquely identified and traceable to the specific claim(s) it supports. The traceability must be maintained in a persistent, version‑controlled repository.

Evidence Quality Attributes

For each evidence item, the standard requires that the following quality attributes be documented and justified:

  • Validity – Does the evidence correctly support the claim?
  • Timeliness – Was the evidence obtained under the relevant configuration?
  • Independence – Was the evidence generated by a party free from conflict of interest?
  • Repeatability – Can the evidence be regenerated under controlled conditions?
  • Coverage – Does the evidence address all applicable failure modes and contexts?

Evidence Lifecycle Management

The standard mandates a defined lifecycle for evidence items, from creation to retirement. Key stages include:

  • Identification – each evidence item is tagged with metadata (source, date, responsible party, classification).
  • Verification – evidence is checked for correctness and completeness before inclusion in the assurance case.
  • Maintenance – when the system changes, affected evidence is flagged for update or re‑validation.
  • Archival – obsolete evidence is retained in a read‑only archive for future auditing.
Example Evidence Requirements by Integrity Level (From ISO/IEC 15026‑2‑13 Annex A)
Integrity Level Direct Evidence Required Independence Level Archive Period
4 (Highest) All safety‑critical functions Fully independent third party 30 years
3 Critical functions Independent internal team 20 years
2 Selected sub‑functions Self‑verification with review 10 years
1 Process evidence only Not required System lifetime
Warning: The standard treats tool‐generated evidence (e.g. from simulations or static analysis) as indirect evidence. Such evidence must be accompanied by tool qualification records to verify its reliability.

Implementation Highlights

Adopting ISO/IEC 15026‑2‑13:2017 requires an organization to establish a formal Evidence Management Plan (EMP) early in the project. The EMP should define:

  • Roles and responsibilities for evidence creation, review, and storage.
  • The tool chain for evidence tracking (many teams use a dedicated assurance case management tool that supports traceability matrices).
  • Criteria for accepting or rejecting evidence items (especially where multiple sources exist).
  • Procedures for handling evidence updates triggered by design changes, bug fixes, or regression testing.

A practical first step is to map the existing verification and validation activities to the three evidence classification levels. Often, companies find that much of their current test artefacts qualify as direct or indirect evidence but lack formal traceability to high‑level claims. Building that traceability is the core challenge.

Success: When implemented effectively, ISO/IEC 15026‑2‑13:2017 provides a defensible evidence base that greatly simplifies regulatory audits and certification efforts, particularly for multi‑domain systems (e.g. medical + safety‐critical software).

Compliance and Certification Notes

ISO/IEC 15026‑2‑13:2017 is a normative standard, not merely a guideline. Organizations claiming compliance must demonstrate that their evidence management process meets all the requirements in clauses 5 through 8. Key compliance points include:

  • The existence of a live, version‑controlled evidence repository that is accessible to all stakeholders.
  • Evidence quality attributes are documented for every item and reviewed at project milestones.
  • Traceability from evidence to claims is maintained bidirectionally (both forward and backward).
  • An independent reviewer (internal or external) has assessed the evidence set for completeness and consistency before the final assurance case is issued.

Because the standard is relatively recent (2017), certification bodies may not yet have formal scope for auditing to this specific part. However, it is increasingly referenced in audit checklists for IEC 61508, ISO 26262, and ISO 13485. It is advisable to include the standard explicitly in the project’s certification plan and to request its coverage during any third‑party assessment.

Important: Failure to properly manage evidence can lead to an assurance case being rejected during certification, resulting in costly rework and project delays. The standard makes clear that missing or poorly maintained evidence voids the traceability chain, effectively invalidating the entire case.

Frequently Asked Questions

Q: How does ISO/IEC 15026‑2‑13:2017 relate to the main assurance case standard (ISO/IEC 15026‑2:2017)?
A: ISO/IEC 15026‑2 defines the overall structure of an assurance case (claims, arguments, evidence). The ‑2‑13 part adds detailed requirements specifically for the evidence management sub‑process. It assumes the user already has an assurance case framework in place and wants to strengthen the evidence handling practices.
Q: Is this standard applicable only to safety‑critical systems?
A: While it was conceived with high‑integrity systems in mind, the evidence management principles are domain‑agnostic. Any project that requires an auditable justification of system properties (e.g., security, reliability, business continuity) can benefit from the standard’s structured approach.
Q: What tools are recommended for tracking evidence as per the standard?
A: There is no tool mandate. However, the standard requires version control, traceability, and persistent storage. Many projects use ALM (Application Lifecycle Management) tools with requirements management and test management modules, or dedicated assurance case software (e.g., Goal Structuring Notation tools) that support evidence linking. The key is that the tool must enforce the required quality attributes and access controls.
Q: Can existing evidence (e.g., from a previous project) be reused?
A: Yes, but only if it meets the quality, traceability, and timeliness requirements of the current context. Reused evidence must be re‑assessed and explicitly linked to claims in the new assurance case. The standard warns against generic or out‑of‑date evidence unless thoroughly justified.

© 2026 – Published for informational purposes. Always refer to the latest official version of ISO/IEC 15026‑2‑13 for compliance.

📥 Standard Documents Download

🔒
Please wait 10 seconds, the download links will appear after the ad loads

Leave a Reply

Your email address will not be published. Required fields are marked *