Software teams often assume that ISO 13485 design controls mean a parallel world of Word documents and wet signatures. They don't. Clause 7.3 of ISO 13485:2016 and the activities in IEC 62304 can be evidenced from the tools your team already uses, provided those tools are configured, controlled and validated, and you can export a coherent record when an auditor asks. This guide shows one practical setup in Jira and GitHub. The same logic works in Azure DevOps, GitLab or Linear.

A note on the standards. ISO 13485 and IEC 62304 are copyrighted and not freely available. Clause numbers and titles below were checked against official previews and certification-body summaries (see Sources). Requirements are paraphrased, not quoted. Work from your own licensed copy when you write procedures.

What an auditor looks for in design controls

Whatever the tool, the questions are the same. Is there a plan? Are inputs documented, including functional, performance, usability and safety requirements? Are outputs in a form that can be verified against inputs, and approved before release? Are reviews recorded with what was reviewed, who took part and when? Are verification and validation planned with acceptance criteria and recorded? Are changes assessed, approved before implementation and verified? Is there a design and development file that ties it together? Tools are acceptable evidence when two conditions hold:

  • software used in the QMS has been validated for its intended use (clause 4.1.6)
  • the records it holds are controlled (clause 4.2.5)

Mapping ISO 13485 clause 7.3 and IEC 62304 to Jira and GitHub

ISO 13485:2016IEC 62304 activityImplementation in Jira / GitHubRecord an auditor will ask for
7.3.2 Design and development planning5.1 Software development planningA controlled software development plan that names the Jira project, issue types, workflows, Definition of Done, branching and release strategy. One Jira version per planned release.Approved plan with version history. Release plan.
7.3.3 Design and development inputs5.2 Software requirements analysisIssue types User Need and Software Requirement. Fields: rationale, acceptance criteria, verification method, safety relevance. Links: "derives from" (to user need) and "implements" (to risk control).Approved requirements baseline per release.
7.3.4 Design and development outputs5.3 Architectural design; 5.4 Detailed design; 5.5 Software unit implementationArchitecture and design documents kept in the repository and changed through pull requests. Code merged only through pull requests that reference a requirement or change key. Branch protection with required reviews.Approved architecture version. Merged PRs with reviewer approvals.
7.3.5 Design and development reviewReviews defined in the plan (5.1)Issue type Design Review per milestone: scope (versions, documents), participants, decisions, linked actions. Sprint reviews count only if they are recorded this way.Review record: what was reviewed, who took part, date, actions.
7.3.6 Design and development verification5.5 unit, 5.6 integration and 5.7 system testing; 7.3 Verification of risk control measuresTest cases in a test-management app or in the repository. CI runs tied to commit SHA and build number. Test reports exported to controlled storage. Jira link "verified by" from each requirement to its tests.Protocols with acceptance criteria. Results on an identified build. Traceability from requirement to test to result.
7.3.7 Design and development validationDevice-level validation, for example IEC 62366-1 summative evaluation and clinical evaluationValidation issues linked to user needs. Plan and report stored as controlled documents, carried out on a release candidate representative of the final product.Validation plan and report on an identified version.
7.3.8 Design and development transfer5.8 Software releaseIssue type Release with its own workflow. Git tag and GitHub release. Build provenance. Release notes and a list of known anomalies. Deployment record.Release record with QA/RA approval. Identified build. Known anomalies evaluated.
7.3.9 Control of design and development changes6 Software maintenance; 7.4 Risk management of software changes; 8.2 Change control; 9 Problem resolutionIssue types Change Request and Problem Report with impact-assessment fields and approval before implementation.Change record: reason, impact, risk review, regulatory assessment, approval, verification.
7.3.10 Design and development files8.1 Configuration identification; 8.3 Configuration status accountingA controlled design history index per release that references saved Jira queries, exports, repository tags and CI report archives.Index plus exports for each released version.

Workflows that create evidence by default

The point of a workflow is that the record exists because the work happened, not because someone remembered to write it up afterwards.

Illustrative example

Issue typeStatesWho may approveRequired before the key transition
Software RequirementDraft → In review → Approved → (Change pending → In review)Product owner + QA/RA (not the author)Rationale, acceptance criteria, verification method, link to user need or risk control
Risk Control MeasureProposed → Implemented → VerifiedRisk owner + QA/RALink to the hazard ID in the risk file, implementing requirement and verifying test
Change RequestSubmitted → Impact assessed → Approved → Implemented → Verified → ClosedChange board (engineering, QA/RA, clinical where relevant)Impact on intended purpose, risk, clinical evidence, cybersecurity, labelling; regulatory assessment, including whether the Notified Body must be involved
Problem ReportOpen → Investigated → Change requested / Not fixed (with rationale) → Verified → ClosedQA/RA for "Not fixed"Safety relevance evaluated; trend category assigned
Design ReviewScheduled → Held → Actions closedReview chairScope (versions and documents), participants, decisions, actions
ReleasePlanned → Release candidate → Verified → Approved for release → ReleasedQA/RA + release ownerAll linked requirements verified, anomalies evaluated, release notes, validation status, build ID

Use Jira workflow conditions and validators to enforce these rules. For example, block "Approved" when the approver is also the assignee, and block "Approved for release" while linked requirements are unverified. Restrict who can edit workflows.

On the GitHub side

  • Branch protection on release branches: required reviews, required status checks (build, tests, static analysis), and no direct pushes.
  • CODEOWNERS for safety-relevant modules, so the right reviewer is pulled in automatically.
  • A pull request template with a Jira key, risk impact (yes/no and why), test evidence, and documentation updated (yes/no).
  • Tags and releases that match the Jira Release issue, with the build identifier recorded in both.
  • CI evidence exported to controlled storage. CI platforms delete artifacts after a configurable retention period, and a technical file must remain available for at least 10 years after the last device is placed on the market (Article 10(8) MDR).
  • A dependency inventory generated from the build and reviewed at each release. It is the practical basis for SOUP documentation and for monitoring vulnerabilities.

Validating Jira and GitHub as QMS software (clause 4.1.6)

ISO 13485 requires documented procedures for validating computer software used in the QMS. Validation happens before first use and again after changes. You are not validating Jira as a product. You are validating your configuration for your intended use. ISO/TR 80002-2:2017 gives guidance on validating software used in medical device quality systems. Scale the effort to what could go wrong if the tool fails. A workable approach:

  1. Intended use statement for each tool. Example: "Jira holds design inputs, risk control links, change and problem records, and release approvals for product X".
  2. Risk assessment. What happens if the tool loses a link, lets the wrong person approve, or silently changes a record?
  3. Configuration specification: issue types, fields, workflows, permissions, automation rules.
  4. Tests of the controls that matter. An author cannot approve their own requirement. A release cannot be approved with unverified items. History is retained. Exports are complete.
  5. Revalidation triggers: workflow or permission changes, new automation, and vendor changes that affect the validated functions. For cloud tools, monitor the vendor's release notes.

Records, approvals and signatures

ISO 13485 controls documents under 4.2.4 and records under 4.2.5. FDA's QMSR final rule puts it this way: "Records are a special type of document and shall be controlled according to the requirements given in 4.2.5." In a Jira/GitHub setup, auditors usually focus on a few questions:

  • Attribution. Every approval is tied to a named individual with defined authority. Use personal accounts only, with no shared logins.
  • Link to the exact version. A PR approval applies to a specific commit. A requirement approval should apply to a specific revision, so editing an approved item must reopen review.
  • Integrity and history. Edits are logged, deletion is restricted, and admin actions are controlled.
  • Retention and retrieval. Records stay readable for the retention period you define. That period must cover the MDR's 10-year minimum for technical documentation, even if you change tools or the subscription ends.

For the EU, what matters is that approvals are attributable, dated and controlled. If you also sell in the United States, FDA's 21 CFR Part 11 applies to electronic records created or maintained under FDA record requirements (11.1(b)). Check whether your tools and procedures meet it.

Traceability exports for auditors

Notified Body auditors rarely work inside your Jira. Prepare a controlled export for each release:

  • the requirements list with status, approver and approval date
  • a trace matrix: user need → software requirement → risk control → test → result (with build ID)
  • change requests and problem reports closed in the release
  • known anomalies with their evaluation
  • the release approval record

Save the JQL queries or scripts that produce the exports as controlled documents, so the export can be reproduced. Store the exported files (PDF or CSV, time-stamped) in your document system, referenced from the design history index. Annex II 6.1(b) MDR expects evidence of the software's validation as used in the finished device, including test results obtained before final release. These exports are where that evidence comes from.

Example: one requirement's trail

Illustrative example

Fictional records, written for this guide. Here is one fictional requirement traced from the user need to the release.

  • UN-12 (user need): nurses need to see why the app suggested an urgency level.
  • SR-142 (software requirement, derives from UN-12): the app displays the suggested urgency together with the input values used. Approved by the product owner and QA/RA, revision 3.
  • RCM-07 (risk control measure): implemented by SR-142. It mitigates hazard H-03, "suggestion misread or trusted without context", in the risk file.
  • PR #318 (pull request): references SR-142, has two approvals, and its required checks passed. Merged as commit a1b2c3d.
  • TC-221 (test): automated system test linked as "verified by". It passed on build 2.3.0-rc2 in CI run 4471, and the report was exported to the document system.
  • REL-2.3.0 (release): all linked items verified. The two known anomalies were evaluated as not safety-relevant. Approved for release by QA/RA and tagged v2.3.0.

Common pitfalls

  • The person who implemented a change also approves it, because the workflow allows it.
  • Tests pass on a development build, and the released build is not the one that was tested.
  • "Done" in Jira is used to mean "verified", with no separate verification state.
  • Bugs are closed as "won't fix" without a documented safety evaluation.
  • Workflow or permission changes are made by an admin without revalidation.
  • There is no design history index, so every audit starts with an improvised search.

If you want this set up around your existing workflow, see our ISO 13485 QMS implementation. If you prefer to do it yourself with ready-made procedures, see our QMS templates. For the software lifecycle requirements behind the mapping, see the IEC 62304 guide. For release-level change control of AI models, see AI/ML SaMD change control.

Sources