When you connect GitHub or GitLab, ComplyJet only sees the repositories that connection was actually granted access to — not your entire organization by default, unless you chose that.
Where scope is set
Repository access is a property of the GitHub App installation (or GitLab access token) itself, not a setting inside ComplyJet. To change it:
Go to Setup → Integrations and find your GitHub (or GitLab) card.
Click Manage, then Update on the connected account.
This takes you into the provider's own installation/permissions screen, where you choose between All repositories or Only select repositories — and, in the latter case, which specific ones.
Whatever you choose there is what ComplyJet can evaluate — repository-based tests (branch protection, PR review requirements, vulnerability scanning, etc.) only run against in-scope repos. A repository excluded at the installation level is invisible to ComplyJet entirely; it won't show up as a failing test or missing evidence, because ComplyJet has no visibility into it.
Why this matters for an audit
If you deliberately exclude a repository (e.g. an archived project, a personal fork, or something with no production relevance), that's a legitimate scoping decision — but be ready to explain it if an auditor asks why a given repo isn't reflected in your controls. Keeping scope intentional and documented (rather than accidental, from an installation that was never revisited since initial setup) is the safest way to handle this.
If you add new repositories on the provider side later, revisit the installation settings to make sure they're included — new repos aren't automatically in scope unless you originally selected All repositories.