Security activities in the development lifecycle

IEC 81001-5-1:2021 · Clause 5 — Security activities in the product lifecycle

Overview of Clause 5 structure

Clause 5 is the core of IEC 81001-5-1. It is structured as a sequence of security activities that map directly onto the software product lifecycle:

1. §5.1 — Security planning
2. §5.2 — Security requirements (including TARA)
3. §5.3 — Secure design
4. §5.4 — Secure implementation
5. §5.5 — Security verification and validation testing
6. §5.6 — Security release documentation
7. §5.7 — Security activities after release (covered separately in Article 4)

§5.1 — Security planning

Before development begins, the organisation shall establish a Security Plan that defines: the security activities to be performed; the resources and responsibilities assigned to each activity; the security testing strategy; the criteria for passing each security activity; and the schedule of activities relative to the software lifecycle. The Security Plan is typically a section within or annex to the Software Development Plan required by IEC 62304 §5.1.

The Security Plan must also define the intended use environment (deployment context), identify trusted and untrusted boundaries of the software system, and establish the security architecture principles that will govern the design.

§5.2 — Security requirements and TARA

Security requirements are derived from the Threat Analysis and Risk Assessment (TARA). This is the security equivalent of the hazard analysis required by ISO 14971. The TARA process requires the organisation to: enumerate the software system assets; identify threat actors and their capabilities; identify attack surfaces; enumerate threats using a structured methodology (e.g., STRIDE); estimate the likelihood and impact of each threat; and determine whether security controls are needed.

Each identified threat that exceeds the risk acceptability threshold generates one or more security requirements. These requirements are documented in the Security Requirements Specification, which in turn informs the architectural and detailed design activities.

§5.3 — Secure design

Secure design translates security requirements into architectural and detailed design decisions. IEC 81001-5-1 §5.3 requires that the software architecture demonstrates how each security requirement is addressed. Key secure design principles include: least privilege (components operate with the minimum permissions necessary); defence in depth (multiple layers of security controls); fail secure (failure modes do not open security gaps); and separation of duties for sensitive operations.

The design phase must also address the security of interfaces — particularly those exposed to the network, external devices, or user input. API security, authentication, encryption at rest and in transit, and session management must each be explicitly designed and documented.

§5.4 — Secure implementation

Secure implementation covers the coding practices and tooling used to reduce the introduction of vulnerabilities during development. IEC 81001-5-1 §5.4 requires: use of secure coding standards (e.g., CERT C/C++, OWASP); static application security testing (SAST); software composition analysis (SCA) to identify known vulnerabilities in third-party components (SOUP/OTS); peer review with security perspective; and prevention of common vulnerability classes (injection, buffer overflow, insecure deserialisation, etc.).

§5.5 — Security verification and validation testing

Before release, the software must undergo security-focused testing activities. IEC 81001-5-1 §5.5 distinguishes between:

• Security functional testing — verifying that each security requirement is implemented correctly
• Vulnerability scanning — automated scanning for known vulnerability classes
• Penetration testing — adversarial testing of the deployed system or component
• Fuzzing — automated injection of malformed inputs to identify unexpected failure modes

The depth of testing required scales with the security risk classification of the software. High-risk configurations (e.g., internet-connected SaMD processing patient data) require penetration testing by qualified security testers. All test activities must be documented with a Security Test Report.

§5.6 — Security release documentation

Before a software version is released, the organisation must produce and approve a set of security release documents. These include: the Security Architecture Document; the Security Risk Management Report (summarising TARA outcomes and residual risks); the Security Test Report; the Software Bill of Materials (SBOM) listing all software components and their versions; and the Customer Security Manual (minimum IT security requirements for deployment).