When a quality management system (QMS) runs on spreadsheets, a traceability matrix is only as current as the last time someone updated it by hand. That may work for a single review cycle, but it doesn't survive a software as a medical device (SaMD) team that works in Jira and GitHub and ships every two weeks.
Building a traceability matrix is one thing, but keeping it up to date automatically, especially when working at the speed of modern software teams, is something else entirely. Today we're going to look at what happens when a team starts shipping on a real cadence and the question is no longer about building the matrix but how to keep it up to date and audit-ready.
The spreadsheet drift problem
Most SaMD teams start with a spreadsheet or a static export, and it works fine for the first review. Then engineering keeps moving. A requirement gets split into three tickets or a test case is rewritten after a design change. Maybe a feature ships under a different name than the one in the original user need. Each of these is a normal part of iterative development, but none of them are reflected in the matrix unless someone remembers to do it by hand.
That's the drift. The matrix reflects the system as it existed on the last day it was updated, not the system as it exists in production. An auditor pulling a thread from a released feature back to its originating requirement will find a broken link, a stale test reference, or a row that was never created because the ticket that satisfied it didn't exist yet when the matrix was built.
The root cause is simply a structural mismatch between how engineering works and what the tools they are using to fulfill regulatory requirements can do. Requirements, code, and test evidence live in tools built for speed (Jira, GitHub, continuous integration (CI) pipelines), while the traceability record lives in a tool built for static documentation. Every sprint widens the distance between the two.
That mismatch is a problem during audit prep. Someone has to reconstruct months of engineering history via memory and tribal knowledge. A quality engineer pulls up the matrix, finds three requirements with no linked ticket, and starts messaging developers to ask which pull request actually closed them out. The developers, several sprints removed from that work, have to go digging through git history to answer a question the tooling should have answered on its own. Multiply that across a submission with hundreds of requirements, and the reconciliation effort rivals the original development work.
What automated traceability actually requires
Closing that gap takes more than a faster export. Four things have to be true for traceability to hold up without manual reconciliation.
- First, a single data model has to connect a requirement ID to its design output, its implementing commit or pull request, its test case, and the release it shipped in. Copy-pasting the same identifier across four separate tools is not a data model, it's a chain of manual steps waiting to break.
- Second, the links have to update live. If a matrix updates on export, it's already stale the moment engineering merges the next commit. Traceability that updates when the ticket or commit updates, rather than on a quarterly audit-prep cycle, is the only version that reflects what actually shipped.
- Third, the traceability has to run in both directions. Forward, from requirement to test evidence, answers "did we verify this?" Backward, from a specific commit to the requirement and risk control it satisfies, answers "what does this line of code exist to do?" A team that can only answer the first question is still exposed the first time a reviewer asks the second.
- Fourth, the resulting audit trail has to survive without someone assembling it under deadline. Version history, change control, and linkage all need to come from the actual development activity in Jira and GitHub, not from screenshots taken the week before a submission. Closed-loop traceability as a QMS requirement means the loop closes on its own, not that someone closes it manually before the auditor arrives.
In practice, the linking has to happen where the work already happens. If a developer references a requirement ID in a commit message or a pull request description, that reference must become a permanent, queryable link rather than a note someone has to transcribe later. A test suite must report pass or fail status back to the requirement it verifies as part of the same CI run. A risk control tied to a design change should surface automatically the moment that change is proposed, so the question of what evidence needs updating is answered before the merge, not after an auditor asks.
Greenlight Guru helps software teams achieve traceability without leaving their tools
None of this works if it asks engineers to leave the tools they already use. A quality system that requires a developer to log into a separate portal to update a traceability row is a quality system that will be updated once and then ignored. The traceability record has to sit inside the same Jira tickets and GitHub pull requests where the actual work happens, so the link is made as a side effect of normal development rather than as a separate compliance task.
Greenlight Guru's eQMS includes native Jira and GitHub integrations built for this context. If your team is already running IEC 62304-structured software development, the path from your existing dev stack into a compliant quality record is shorter than it usually looks.
Get your free demo of Greenlight Guru today and see how an eQMS built for Jira and GitHub-native SaMD teams keeps traceability current automatically.
BONUS RESOURCE: SaMD Gap Assessment Tool
