Most quality management systems were built for hardware. QMS frameworks grew up around design freezes, physical bills of materials, and a release cadence measured in months. Software doesn't work that way, and pretending it does is where a lot of engineering teams start resenting their QMS.
Ashkon Rasooli, a MedTech QMS strategist, joined us recently for a webinar built entirely around that challenge. I sat in on it, and one framing is something I want to walk through here: the idea of a system of entry versus a system of record.
Here's part of the pattern Ashkon laid out. Your engineers live in Jira, GitHub, or whatever your team's actual development tool is. That's the system of entry, where work gets created, tracked, and moved. Your quality management system (QMS) is supposed to be the system of record: the place that proves, later, that the work happened the way it needed to happen.
Most software QMS setups ask engineers to do their real work in one tool and then re-enter a shadow version of it in another. Write the ticket in Jira, then write it again in the QMS. Close the ticket, then go update a second record so an auditor can find it in six months. I've started calling this the translation tax, and it's a tax paid by the people whose time is hardest to get back.
Ashkon's framework doesn't try to eliminate the QMS side of that equation. IEC 62304, the international standard for medical device software lifecycle processes, isn't optional, and neither is a defensible design history. The fix isn't less rigor. It's rigor that doesn't require a second copy of the same work.
I appreciated that the session didn't treat agile and compliant as opposites a team has to choose between. Ashkon walked through what a QMS manifesto might look like for software teams: principles that favor working software and fast feedback over ceremony for its own sake, without dropping the controls that IEC 62304 and design controls actually require.
Culture versus mandate was the distinction he kept returning to. A QMS imposed on engineers as a compliance tax gets worked around. A QMS built with an understanding of how software teams actually ship gets used, because it isn't fighting the workflow underneath it.
We spent real time on the mechanics: software safety classification (A, B, or C, based on the harm a failure could cause), and how that classification should scale the rigor a team applies, not just to test coverage but to your whole software development lifecycle. A Class C component and a Class A component shouldn't carry the same documentation burden. Treating them identically is its own kind of waste.
IEC 62304 also gets confused with something it was never meant to be: a coding standard. It doesn't care what language a team writes in or which framework it uses. It cares about the process and the records that process leaves behind, which is exactly why it can coexist with agile when teams design for that on purpose instead of bolting compliance on after the fact.
Risk management got its own section, and rightly so. Risk-benefit balance is what should drive how much verification a given change actually needs. Ashkon connected this directly to verification testing, where teams either overdo it (testing everything to the same exhaustive standard regardless of risk) or underdo it (skipping documentation because "it's just a small fix").
A risk-based approach to verification tracks closely with what computer software assurance (CSA) is trying to push teams toward: match your testing rigor to the actual risk of the change, and document accordingly rather than running the same checklist every time regardless of stakes.
For me, the most practical part of the webinar was the section on evaluating a QMS built for teams that ship continuously, not teams that run periodic design freezes. That calls for a different kind of platform, one where your application lifecycle management tools and your quality records stay connected instead of living in two disconnected systems someone has to manually reconcile before every audit.
Ashkon also touched on security and safety integration, and briefly on how teams are starting to validate AI-assisted development tools inside a regulated software development lifecycle. Both are still moving targets. The underlying principle held regardless: whatever sits in your stack, from cybersecurity monitoring to AI-assisted coding, needs a place in your risk and verification story, not a side door around it.
The session closed on culture change, and Ashkon was clear that this isn't a one-time rollout. Publishing a new SOP and hoping engineers read it won't fix the translation tax. What fixes it is making the compliant path the easy path, so following the process becomes the path of least resistance instead of the one people route around under deadline pressure.
Don't just breeze past that last part.. A software QMS earns trust from engineering teams the same way any tool does: by being less annoying to use than the workaround.
If you're building out your software QMS process, these related guides go deeper on the specific components:
If you want to see what a QMS built for that kind of continuous, no-design-freeze workflow actually looks like, that's the specific gap a platform like Greenlight Guru's was built to close.