Jira is Atlassian’s issue and project-tracking software. Medical-device development teams frequently use it as part of an application lifecycle management environment for planning work, managing requirements, tracking defects and linking design activities for traceability.
A standard Jira configuration is not automatically compliant with IEC 62304. Medical-device teams must add appropriate configurations, plugins, validated overlays or integrations to produce the traceability, approval and audit-trail evidence required for regulated software development.
What is Jira?
Jira is a configurable workflow and issue-tracking platform developed by Atlassian. It organizes work into issues—such as stories, tasks, requirements and defects—that move through defined statuses and approval workflows.
Application lifecycle management means managing a product from requirements through development, testing, release and maintenance in a connected system. Engineering teams use Jira as a day-to-day record of what needs to be built, who owns each activity and its current status.
In a medical-device software program, Jira generally operates at the planning and execution level. It can hold user stories, design activities, software requirements, defects and test tickets. By default, however, it is neither a formal Design History File repository nor a validated requirements-traceability system.
That distinction matters because regulators expect demonstrable connections between user needs, design inputs, software requirements, architecture, implementation, risk controls and verification evidence. A standard Jira configuration does not automatically produce all this evidence.
Why Jira matters in medical device development
Traceability is not optional in regulated medical-device software. IEC 62304 requires documented connections between software requirements, architecture, detailed design, implementation and testing. ISO 13485 Clause 7.3 requires design outputs to be traceable to their corresponding design inputs.
Under the FDA Quality Management System Regulation, effective February 2, 2026, ISO 13485:2016 is incorporated by reference into 21 CFR Part 820. This means that demonstrable design and development traceability forms part of the US regulatory expectation.
The audit implications are practical. During an FDA inspection or notified-body audit, an assessor may select a high-risk requirement and ask the development team to trace it to the relevant risk control, architecture element, code module and verification test, and then back to validation evidence.
The primary tool used to demonstrate this coverage is a Requirements Traceability Matrix (RTM). A broken or incomplete traceability chain can prevent the team from demonstrating that the device was developed and tested according to approved requirements.
Because Jira is familiar to software developers, many teams choose it as their initial project-management tool. The risk is treating a general-purpose tracker as if it already satisfies medical-device design controls. Jira can support the process, but the compliant evidence model must still be designed, implemented and validated around it.
How Jira works in a regulated workflow
When configured appropriately, Jira can support several parts of the medical-device design-controls process:
- Requirements as issues: User needs, design inputs, system requirements and software requirements can be configured as separate issue types. Parent-child relationships and controlled link types can establish connections between them.
- Design and implementation tasks: Development work items can link back to the requirements they implement, creating a documented path from an approved requirement to the resulting design or code change.
- Test and evidence records: Test cases and results can link to the requirements and risk controls they evaluate, supporting documented verification and validation coverage.
- Defect management: Software defects can be recorded, classified, investigated and linked to affected requirements, risk controls, code changes and regression tests.
- Workflows as review gates: Custom statuses, permissions and transitions can enforce review and approval activities aligned with a controlled Phase-Gate Process.
- Release planning: Versions, milestones and release records can help teams organize approved software changes and confirm that required activities are complete before release.
The main gaps appear around formal evidence. A standard Jira configuration does not automatically generate a compliant RTM, provide electronic signatures aligned with FDA 21 CFR Part 11, or create the immutable and time-stamped audit trails expected for controlled quality records.
Medical-device teams generally address these gaps in one of three ways:
- Add compliance-focused plugins that provide electronic signatures, controlled baselines, formal reviews and locked records.
- Use a validated overlay that converts Jira data into a regulated requirements and traceability environment while maintaining a familiar interface.
- Integrate Jira with a purpose-built ALM or requirements-management platform, such as Jama Connect, Polarion or Codebeamer. The dedicated platform owns the formal requirements and traceability evidence, while Jira continues to manage daily development activity.
Regardless of the chosen approach, the organization must define the tool’s intended use, assess its risks, validate the configured system and retain evidence that it performs consistently for its regulated purpose.
Common challenges and best practices
A common failure is building the RTM by exporting Jira data into spreadsheets and reconciling the information manually. This approach is error-prone, difficult to maintain and increasingly fragile as the software and number of requirements grow.
Another mistake is attempting to build traceability retrospectively shortly before a regulatory submission. Missing relationships then require teams to reconstruct months of design decisions, code changes and test results, increasing both rework and audit risk.
Teams also sometimes confuse sprint planning with regulated design planning. Sprints organize development work, but they do not replace the approved design and development plan, the IEC 62304 software safety classification, risk-management activities or the documented verification strategy.
Good practice includes:
- Define issue types and link types according to the organization’s design-controls and software-development procedures.
- Maintain the traceability chain as development occurs instead of reconstructing it before an audit or submission.
- Distinguish user needs, design inputs, system requirements, software requirements, risk controls, implementation tasks, defects and tests.
- Restrict who can approve, modify or close controlled records.
- Establish clear review and approval states rather than relying on informal comments.
- Baseline requirements before formal verification begins.
- Link every approved change to impact analysis, risk review and appropriate regression testing.
- Decide early whether Jira, a validated plugin, an overlay or an external ALM platform will own the formal regulatory evidence.
Agile development is compatible with medical-device design controls. AAMI TIR45 provides guidance for using Agile practices in regulated software development, provided that each iteration generates and maintains the required documentation and traceability. Configuring the evidence model early is substantially less expensive than remediating a broken traceability system during an audit.
How SJML helps with Jira
SJML supports the engineering and regulatory disciplines that project-management tools such as Jira must serve. Through its medical device design and engineering capabilities, SJML helps teams define software requirements, architecture, traceability structures, review gates, verification activities and controlled design changes across the IEC 62304 lifecycle.
SJML’s medical device compliance services align these development records with ISO 13485, ISO 14971, FDA and EU MDR expectations. Engineering and QARA teams work together across design controls, software risk management, verification, design transfer and structured change control.
This approach allows the required evidence to remain consistent and auditable regardless of whether the client uses Jira independently, a compliance overlay or an integrated ALM platform.
Frequently asked questions
No. Jira is a general-purpose issue and project tracking tool, and a stock configuration does not meet IEC 62304 on its own. It lacks native requirements traceability matrix generation, electronic signatures, and immutable audit trails. Teams reach compliance by adding validated plugins or overlays, or by integrating Jira with a purpose-built ALM system validated for its intended use.
Teams model user needs, requirements, design tasks, and test cases as linked Jira issues so each requirement connects to its implementation and verification. Because stock Jira does not export a compliant matrix, most add a compliance plugin or integrate with an ALM platform that generates the RTM automatically. Maintaining these links as work happens avoids rework near submission.
Yes. Agile development is compatible with design controls when each sprint produces the documentation regulators expect. AAMI TIR45 provides guidance on aligning Agile with regulated device software. Jira suits this model, since boards and sprints match how Agile teams already work. The requirement is that user needs, risk controls, and verification stay traceable throughout, not reconstructed afterward.
Stock Jira lacks three things regulated software needs: automated, current requirements traceability; electronic signatures aligned to FDA 21 CFR Part 11; and locked, time-stamped audit trails showing who changed each record and when. Teams fill these gaps with compliance plugins, validated overlays, or integration with a dedicated ALM tool that owns the formal design evidence.
