Kaloko in quality-managed and regulated work
For teams that work under ISO 9001, ISO 13485, IEC 62304, ISO 27001 or GxP and have to show what was tested, on which version and who approved it. Kaloko records that and hands it to your own quality system as evidence you can check.
Who it is for
- Software teams in medical devices that work under ISO 13485 and IEC 62304
- Quality and validation people in pharma and biotech, where 21 CFR Part 11 and EU GMP Annex 11 apply
- Companies with an ISO 9001 or ISO 27001 management system that release web and mobile applications
- Agencies and suppliers whose clients ask for test records with every delivery
What is hard to prove later
Half a year after a release, an auditor asks how requirement URS-12 was tested. Which build was it, what did the screen look like, who looked at it and who approved it? The answer is spread over a spreadsheet, three screenshots in a ticket and the memory of someone who has since moved teams.
What Kaloko gives you today
- Requirement references and a trace matrix
Write the IDs from your tracker or QMS into the scenario. The trace matrix has a row for every requirement, criterion, step, language and screen size, with the screenshot, its hash, the result and the decision.
- Execution and acceptance records
Every run gets a record of what was walked, on which version, with which tools, and what people decided. An accepted run gets an acceptance record. Both list the SHA-256 of every screenshot and are signed by the service.
- Optional electronic signatures
Turn them on and the person who accepts a run picks what the signature means from your list and confirms a fresh second step. The record shows their name, the time with their time zone and the meaning. Agents and tokens never sign.
- An audit trail
Decisions, verdicts, signatures, withdrawn signatures with their reason and record downloads are logged with who, when and through what: a browser, a token or an agent.
- An evidence package you can verify offline
One zip with the record, the trace matrix, the audit trail, the screenshots and a signed list of every file. kaloko signoff --verify checks it against our public key without an account.
- API, MCP and a webhook
The evidence.ready webhook tells your own repository or job that a run was shared, accepted or returned. The job pulls the evidence over the API, checks it and fills your templates, and your eQMS takes it from there.
How it fits your framework
The clauses are where auditors usually look for this kind of record. What counts as evidence is your QA’s decision.
| Framework | How Kaloko helps | What stays with you |
|---|---|---|
| ISO 9001 | Records that cannot change unnoticed (7.5), verification records from design and development (8.3.4), and an acceptance record that says which criteria, which version and who accepted (8.6) | Document control, your archive and the release decision |
| ISO 13485 | Material for validating software used in your QMS: a pinned CLI, our change control, tool versions in every record (4.1.6); protected, identifiable records (4.2.5); verification and validation results traced to requirements (7.3.6, 7.3.7) | Validating your use of Kaloko by risk, retention, the verification and validation plan |
| IEC 62304 | Traceability from requirement to test to result; software system test records with the version, tools, date and the person who decided; input for the release record | The development plan, safety classification, risk management and the release itself |
| ISO 27001 | Acceptance criteria and results as a record of security testing in development and acceptance (A.8.29); acceptance tied to a version, a pull request and people (A.8.32); a package an auditor verifies offline | The ISMS, risk assessment, Statement of Applicability and your change process |
| GxP: 21 CFR Part 11, EU GMP Annex 11 | Audit trail, access by role and accurate copies of records (§11.10), name, time and meaning on every signature (§11.50), signatures bound to the record (§11.70), a fresh second step when signing (§11.200); material for Annex 11 §4, §9, §12 and §14 | Validation (CSV or CSA), SOPs, training, archiving, and whether our signing meets your reading of §11.200 |
| ISO 26262, IEC 61508 | A supporting tool: records of UI checks as additional evidence | Tool qualification and the safety case |
Two ways teams use it
The default, with nothing to set up. Kaloko records what was walked and who decided what; your own tooling turns the evidence into your documents and people sign them in your eQMS. When nothing was signed in Kaloko, the evidence says signing: none, so nobody has to guess where the signature lives.
On Business and Enterprise an admin turns on electronic signatures for all projects or a few. Accepting a run (and, if you want, approving a step) then asks for a meaning and a fresh second step. Changing a signed decision asks for a reason, and the old signature stays in the record as withdrawn.
In development
We are building these with the first teams that need them. None of it is in Kaloko today, and we will not sell it before it is.
- Controlled documents from formal runs Not available yet
Test protocols and reports from your own templates, with screenshots pinned to a run and a check before approval.
- Trusted timestamps and registered workstations Not available yet
A timestamp from an outside authority on the evidence, and runs signed by a workstation your admin approved.
- Supervised runs Not available yet
A run that waits for a person at marked steps, or records who watched it live.
Which plan you need
| What | Plans |
|---|---|
| Requirement references (refs:) in scenarios, steps and criteria | Every plan |
| Signed acceptance record of an accepted run (JSON and PDF) | Business and Enterprise |
| Evidence of any run or release: trace matrix, run record, audit trail of the run, evidence package, the evidence.ready webhook and get_evidence over MCP | Business and Enterprise |
| Electronic signatures with a meaning and a fresh second step | Business and Enterprise |
| Two-step verification required for everyone, session limits | Business and Enterprise |
| Audit log page and export | Business and Enterprise |
| Company sign-in (SAML, OIDC), SCIM, IP allowlist, audit streaming to a SIEM | Enterprise |
Viewers are free on every plan, so auditors and approvers who only read and comment take no seat. Compare plans →
Questions
- Is Kaloko validated, certified or compliant with 21 CFR Part 11?
- No. Nobody has validated or certified Kaloko, and no software tool is compliant by itself: compliance belongs to your process. Kaloko gives you the records, signatures and audit trail your validation looks at, a supplier summary for your assessment and a list of known gaps, so you can decide how to use it.
- Do we have to sign in Kaloko?
- No. By default Kaloko is the execution record and your people sign the documents in your eQMS. Signing in Kaloko is an option on Business and Enterprise that an admin turns on.
- Can our eQMS pick up the evidence by itself?
- Your own job can. The evidence.ready webhook says a run or a release is ready, and the API, the CLI or MCP gives you the evidence and the package to verify and pass on. Kaloko does not ship a connector for a particular eQMS; the integration lives with you.
- Does AI decide test results?
- Not on its own. An AI evaluator may suggest a result; the record marks it as advisory and names the model. The decisions that count are made by people, and for high-risk criteria you can use deterministic checks instead.
- What does Kaloko not cover yet?
- No SOC 2 report yet, no legal hold, the PDF is not PDF/A, the service cannot be held at a version (the CLI can), the time source is not validated, and signatures are made by the service, not with a personal certificate. The help page lists every known gap.
Talk to us about your QMS
Tell us which framework you work under and where you sign today. We will tell you plainly what Kaloko covers for you and what it does not. support@sinfin.cz