Knowledge
A QMS on plain Git: why it usually fails — and what easo does differently.
The idea suggests itself, especially in technical companies: documents as files, versioning with Git, done — that's the QMS. Practitioners who have watched such attempts advise clearly against it — and yet almost everything about the idea is right. An honest assessment.
The instincts behind it are right
Whoever wants their QMS in Git wants the right things: a complete, tamper-evident history instead of “final_v2_new_FINAL.docx”. Plain files instead of a database silo. Your own documents on your own infrastructure instead of a vendor's. And an exit without a negotiation — whoever leaves takes everything along. Every one of these instincts is legitimate, and none of them is the problem.
Where the attempts actually fail
-
At the people
Commits, branches, merge conflicts: anyone who doesn't work with Git daily cannot operate a git QMS. But a QMS only lives when everyone uses it — production, sales, management. A system only IT can touch starts aging on day one.
-
At document control
ISO 9001 (clause 7.5) requires approval before release, protection from unintended alteration, controlled distribution. Git versions perfectly — but it has no release workflow and no built-in signatures. What's left are workarounds you'll have to explain in the audit.
-
At guidance
A file tree never says “clause 7.2 is missing a document” or “the internal audit is overdue”. Versioning is not quality management — the standard's duties (audits, corrective actions, management review) need someone to know, plan and track them. That's exactly where DIY systems break off.
What practitioners report
This isn't a theoretical worry. OpenRegulatory — a Berlin regulatory firm that has watched several companies attempt exactly this — advises against it in its analysis of open-source QMS routes; in their words, the attempts ended as “major catastrophies”. The publicly findable git-QMS projects are correspondingly abandoned or never finished. Honesty also demands the counterpoint: there are documented wiki QMSs that pass audits and stay in living use for years — auditors audit the system, not the tool. But a wiki, too, provides neither completeness guidance nor audit and CAPA workflows. And: no tool — easo included — guarantees the certificate. The QMS passes the audit, not the software.
easo keeps what's right — and builds what was missing
easo is the answer to precisely these three failure points — without giving up the right instincts. Your documents remain plain files in your git; easo sits on top as the tool:
For the people: an office-grade interface without a single word of Git — a handbook as a process landscape, an editor like a word processor, comments instead of merge conflicts. For document control: guided releases under the four-eyes principle, cryptographically signed and — this is the difference to every workaround — verifiable without easo, with standard tools, described right on the exported PDF. For guidance: a model of the standard with an honest readiness figure that says what's missing, and guided flows for audit, CAPA and management review.
And the exit instinct stays fully intact: the way in is the way out — whoever leaves easo keeps everything: files, history, verifiable signatures.
Frequent questions on QMS and Git
Can I just run my ISO 9001 QMS directly in Git?
Technically yes — in practice, practitioners who have watched such attempts strongly advise against it. Git gives you perfect versioning, but no release workflow, no built-in signatures and no guidance through the standard. And above all, non-technical colleagues cannot operate it — a QMS only the IT crowd can use never becomes a living system.
Where exactly do git-based QMS attempts fail?
At three points. First, people — commits, branches and merge conflicts don't belong in an office workday. Second, document control — ISO 9001 requires approval before release; Git has no release workflow and no signatures. Third, guidance — Git never tells you which mandatory documents are missing or when an audit falls due.
Do auditors accept a QMS kept in Git or a wiki?
Auditors audit the living system, not the tool — there are documented cases of wiki-based QMSs passing audits. What matters is that control, traceability and evidence hold up. Those are exactly the parts a raw-git approach has to rebuild by hand — and that's where it fails in practice.
What does easo do differently from a QMS directly in Git?
easo uses Git as the foundation but never shows it to anyone: an office-grade interface instead of a command line, guided releases with cryptographic signatures instead of workarounds, and a model of the standard that says what's missing and what's due. Git's strengths — complete history, tamper evidence, your own files — are fully preserved.
Do I keep the Git advantages with easo — my own data, no lock-in?
Yes, that's precisely the point. Your documents are plain files in your own repository (GitHub, GitLab or self-hosted). easo doesn't store your content on anyone else's servers — and if you ever leave easo, you keep everything, including the full history and the verifiable signatures.
Stay in the loop
easo is available for macOS — the Windows version is coming soon. Leave us a note and we'll reach out the moment it lands.