---
title: "GitHub and GitLab integration for design controls | Qualio"
canonical: "https://www.qualio.com/integrations/github-gitlab"
updatedDate: "2026-11-02T11:44:40.000Z"
description: "Software requirements read from GitHub or GitLab issues and traced to your tests and the ISO 14971 risk file, for IEC 62304. Qualio reads every hour and writes nothing back."
---

# GitHub and GitLab integration for design controls | Qualio

Software requirements read from GitHub or GitLab issues and traced to your tests and the ISO 14971 risk file, for IEC 62304. Qualio reads every hour and writes nothing back.

## Design controls built from your GitHub or GitLab issues

Qualio reads the issues you choose as requirements, with a link back to each one, and writes nothing to GitHub or GitLab.

## What Qualio reads from GitHub and GitLab

Qualio reads the issues in the repository you choose as requirements, at the levels you name in Qualio, with a link back to each issue.

#### GitHub

- Issues, open and closed, with their number, title, body, state, labels and dates, and a link back. Pull requests are read separately, below
- Commits, with the SHA, message, author, committer and date, and a link back
- Releases and pull requests, with a link back. Commits, releases and pull requests land in the Data Registry as records you can link to and reference from anywhere in Qualio

#### GitLab

- Issues, with their title, description, state, labels, milestone, author and assignees, and a link back
- Issues only. Merge requests, commits and releases stay in GitLab

## Connect GitHub or GitLab in three steps

Approve Qualio's app in GitHub or GitLab. Pick the repository, the labels or state that mark an issue as a requirement, and its product and level in Qualio. Check the preview, then Qualio reads the issues every hour.

## What you get

#### The traceability matrix rebuilds itself on every change

Qualio links each test to its requirement and each risk to the element it controls, and marks any requirement with no test, or risk with no mitigation, before the review.

#### Your engineers stay in the repo, and the design controls keep up

Qualio reads the issues as your engineers write them. When one changes, the requirement in Qualio changes with it on the next read.

#### IEC 62304, assessed against the requirements you already have

Qualio maps IEC 62304 clause by clause to the requirements, tests and risks, reassesses when one changes and recommends a fix for any gap.

## Where it stops

Issue comments, diffs and the contents of your code stay in GitHub and GitLab. Qualio reads the issue, the commit message and the release, not the code

Qualio reads from GitHub and GitLab and writes nothing to either. No label, status or comment travels back

#### If the authorisation expires or the connection fails

If the authorisation expires or the connection fails, Qualio marks it Disconnected on the Integrations page, with a banner, and pauses the reads. Reconnect and they resume. The banner is the only notice

#### Qualio does not look for deletions in GitHub or GitLab

Qualio does not look for deletions in GitHub or GitLab, so an issue deleted there stays as a requirement in Qualio until you remove it. Qualio marks an issue that stops matching your rules, a label taken off for instance, as deleted on the next read; removing it from the design controls is an approval in Qualio

## Guides

## Questions about the GitHub and GitLab integration

### Does our repository have to change?

No. Qualio reads the issues as they are, under the labels or state you pick to mark a requirement, and there is no plugin or issue template to adopt. Your engineers keep writing issues the way they do now, and whatever your rules leave out stays out of Qualio.

### Who needs a seat?

People who write or approve in Qualio pay: the product manager who signs the design review, the person who owns the procedures. Everyone who reads or trains is free. An engineer who writes issues in GitHub or GitLab needs no seat, because Qualio reads the issues in as requirements and the engineer has nothing to edit in Qualio.

### Our requirements are GitHub issues and our tests are in TestRail. Does that work?

Yes. Qualio reads the requirements from the issues and the tests and results from TestRail, Xray or Zephyr Scale, then links each test to the requirement it verifies. Qualio reads issues as requirements only, so the tests have to come from the test tool. Xray and Zephyr Scale need a Jira connection beside them.

### How often does Qualio read GitHub and GitLab?

Every hour, and only what changed since the last read. The first read runs about an hour after you save the connection. The requirement keeps a link back, so an engineer can open the issue from Qualio. Its code is the issue number or one Qualio issues, chosen when you set the connection up.

### What permission does it need?

You approve Qualio's app in GitHub or GitLab, and there is nothing to create. The consent screen asks for more than Qualio uses, GitHub's repo scope and GitLab's api scope among them. Qualio uses them to read issues, plus commits, releases and pull requests on GitHub, and for nothing else.

## See the issues become requirements

See a repository's issues read into Qualio on the demo: each one a requirement at the level you name, with its link back, nothing changed in GitHub or GitLab.