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 and Windows. The newsletter tells you what comes next — new versions and new content, nothing else.