Collect compliance evidence automatically with compliance connectors

Safeguard's compliance connectors link the compliance suite to the systems you already run: your identity provider, cloud accounts, code host and ticket tracker. Safeguard reads each one with read-only access, runs automated tests against what it reads, and records the results as evidence for your controls. No screenshots, and no exported spreadsheets that are stale by Monday.

This post walks the connector catalogue page by page. For each family of systems it covers what Safeguard reads, the narrowest grant to create at the vendor, what the connect form asks for, and the gaps a GRC lead should know about before an auditor finds them. For the bigger picture, our posts on continuous compliance in Safeguard and on automated tests and exclusions explain how tests, controls and frameworks fit together. This one is about the plumbing underneath them.

Key takeaways

• A compliance connector reads a system you run with read-only access and turns what it reads into evidence. Every connector sits under Compliance › Connectors, grouped by category.
• You connect with OAuth, an API token, or the vendor's MCP server. The API token method is always offered. MCP connections serve Search and do not feed compliance tests.
• Every setup guide asks for the narrowest read-only grant the vendor offers. Credentials are encrypted at rest and never shown again.
• Identity providers, cloud accounts, code hosts and ticket trackers each answer different audit questions: who can sign in, how accounts are configured, how changes are approved, and how incidents and leavers are handled.
• Each connector's docs page lists the SOC 2, ISO/IEC 27001 and NIST CSF 2.0 controls its tests map to. A passing test is evidence toward a control, not proof on its own that the control is met.
• Connections fail quietly when credentials expire. Calendar every expiry and watch the card statuses.

Why connectors instead of screenshots

A screenshot proves one thing at one moment, and a control has to operate for a whole period. NIST SP 800-137 defines continuous monitoring as "maintaining ongoing awareness to support organizational risk decisions." NIST SP 800-53 Rev. 5 turns that into control CA-7, which asks for "ongoing control assessments" and ongoing monitoring of metrics at frequencies you define.

A connector is how you meet that in practice. Instead of someone capturing the MFA policy page every quarter, Safeguard reads the policy on a schedule and records each result with a timestamp, the account it came from and the setting it read. We covered the evidence model in what a compliance evidence collector actually does and why a hash beats a screenshot. The question here is narrower: which systems can feed the suite, and what does each one read?

The chain from a system to a control

Keep four layers apart, because each fails in its own way.

1. The connection. A credential for one account of one provider, stored encrypted. Its health shows on the connector card.
2. The test or evidence check. A specific read, such as "2-Step Verification is enforced" or "default branch has no force pushes." Each has a switch in the connector's What this connector collects panel.
3. The control. A requirement in your control set, such as access reviews or change approval.
4. The framework. SOC 2, ISO/IEC 27001, NIST CSF 2.0 and others.

Safeguard's connector pages state the boundary plainly: a passing result "is evidence toward a control, not proof that the control is met on its own." A connector shows that a setting was in place. It does not show that people followed the policy around it, which is why some evidence is still attested.

Before you connect anything

Decide who controls the connector list. Admins decide which connectors members can use, under Settings › Connector access or with Manage connectors on the Connectors page. A connector switched off there does not appear for members, and the server refuses to connect it. Our suggestion: switch off every category you do not use, so nobody connects a personal account to a test that feeds your audit. If a system you run is missing, use Request integration.

Know what kind of record a connector produces. The Connectors page filters by Automated evidence or Connection record only, and each connector's docs page has a "What a connection produces" row. The AWS, Entra ID, Okta and GitHub pages say "Automated evidence collection", ServiceNow says "Automated compliance tests", and BambooHR says "People sync", because an HR system feeds the personnel register rather than a configuration check.

Plan a service identity per system. Most grants are tied to the account that creates them. A GitLab personal access token reads only the groups its user belongs to, and a Jira API token reads as the Atlassian account that made it. If that person leaves, the evidence stops. Our suggestion: create a dedicated, non-interactive identity for Safeguard wherever the vendor allows it, and record its owner in your system inventory.

Three ways to connect, and which one to pick

The connect form offers up to three methods, depending on the connector.

Two details trip people up. Some vendors' OAuth sign-in connects their MCP server rather than their API, so it serves Search but cannot feed tests; the guide for such a connector says to use the API token method. And the setup reference notes for several connectors, including Google Workspace, Trello, Zendesk and Airtable, that the compliance tests "need the credential on the API token tab: an OAuth connection cannot read everything they check."

What happens to your credential

These rules apply to every connector, and they are the first questions a reviewer will ask about the compliance tool itself.

• Encrypted, never shown again. Credentials are encrypted at rest with authenticated encryption. After you save, the card only says a credential is stored.
• Narrowest read-only grant. Where a vendor has no read-only option, the guide and connect form say so, and Safeguard only makes read calls either way. Cloud platforms on that list include Vercel, Netlify, Render and Railway.
• Public https only for self-hosted systems. A self-hosted server, such as your own GitLab, must be reachable at a public https:// address. Safeguard refuses private, loopback and cloud metadata addresses before it sends anything.
• IP allowlists. If a vendor restricts API access by IP, allow Safeguard's outbound address. Ask Safeguard support for it.

Our suggestion: when a vendor offers no read-only credential, record that as an accepted risk in your system register, use the shortest token lifetime the vendor allows, and rotate on a calendar.

Identity and SSO: who can sign in, and how

Identity evidence carries the most weight in an audit, because so many controls depend on it. NIST SP 800-53 AC-2 asks organizations to "create, enable, modify, disable, and remove accounts" according to policy and to "monitor the use of accounts," and IA-2 enhancements (1) and (2) require multi-factor authentication for privileged and non-privileged accounts. NIST CSF 2.0 frames the same ground as PR.AA-01 ("Identities and credentials for authorized users, services, and hardware are managed by the organization") and PR.AA-05, which adds least privilege and separation of duties.

Google Workspace

Safeguard reads users and admins, organizational units and groups, 2-Step Verification and password policies, session length, third-party app access, external Drive sharing, mobile and managed devices, and the SPF, DKIM and DMARC records of your domains. There are two cards: Google Workspace for users, admins, policies, devices, email authentication and the Drive sharing policy, and Google Drive, a separate connection with the drive.readonly grant that collects Drive evidence and can also connect Google's Drive MCP server for Search.

You choose one of two sign-ins:

The connect sheet recommends the service account, and so do we if you want every check. One thing to know before you choose: the Google Workspace page says the Google sign-in covers everything except endpoint management, while the setup reference says the compliance tests for Google Workspace "need the credential on the API token tab." The two pages describe the same connector differently, so treat the service account as the safe choice for full coverage, and after an OAuth connection read the "could not read" results on the card before you rely on it. The six read-only scopes, all under https://www.googleapis.com/auth/, are admin.directory.user.readonly (users and admins), admin.directory.domain.readonly (domains, for the email check), admin.directory.device.mobile.readonly (phones and tablets), admin.directory.orgunit.readonly (which unit a policy applies to), admin.directory.group.readonly (2-Step Verification policies applied to groups) and cloud-identity.policies.readonly (password, session, 2-Step Verification, Drive sharing and API control policies).

The optional scope needs a careful decision. admin.directory.user.security is not read-only: Google has no read-only scope that lists the app tokens a user still holds, and this one can also revoke tokens and sign users out. Safeguard's docs say it never uses the scope to change anything and that only one test uses it, the check on departed users who are still active (idp-leaver-still-active). Without it, that test reports that it could not read, which is not a failure. Our suggestion: decide with your identity owner, write the decision down, and if you leave it out, cover departed users' tokens in your offboarding checklist.

Service account setup. In the Google Cloud console, create a service account (it needs no roles), enable the Admin SDK API and the Cloud Identity API for the project, create a JSON key (Google shows it once) and copy the client ID. A super admin then opens the Google Admin console, goes to Security › Access and data control › API controls › Manage domain-wide delegation, clicks Add new, enters the client ID and pastes the scopes as one line:

https://www.googleapis.com/auth/admin.directory.user.readonly,https://www.googleapis.com/auth/admin.directory.domain.readonly,https://www.googleapis.com/auth/admin.directory.device.mobile.readonly,https://www.googleapis.com/auth/admin.directory.orgunit.readonly,https://www.googleapis.com/auth/admin.directory.group.readonly,https://www.googleapis.com/auth/cloud-identity.policies.readonly,https://www.googleapis.com/auth/cloud-identity.devices.readonly

Google's help page explains why this deserves care: domain-wide delegation "lets you grant client applications permission to access your Workspace users' data without requiring their consent." That is why every delegated scope above is read-only.

In Safeguard, choose Service account (the API token method) and enter the full JSON key and an admin email to impersonate: a super admin, or an admin who can read users, groups and devices. Safeguard reads as this admin and changes nothing. A scope you did not delegate affects only the checks that need it; they report "could not read", naming the scope, and the rest still run. If Google blocks the OAuth sign-in as an unverified app, either use the service account or have an administrator mark Safeguard as trusted under API controls › Manage third-party app access.

What Safeguard checks in Google Workspace:

• 2-Step Verification enforced, and weak second factors disabled
• Administrators: how many, and whether they use phishing-resistant MFA
• Password policy and session length
• Inactive users, and departed users who are still active or still hold app tokens
• Third-party app access restrictions and external Drive sharing
• Phones and tablets in Workspace mobile management, and endpoint management checks (disk encryption, operating system updates and screen lock on phones and tablets, plus devices of people who have left), which need the service account
• SPF, DKIM and DMARC on your domains, read from public DNS

Policies are judged for every organizational unit and group they target, "so a weaker setting on a sub-unit is not hidden by a strong top-level one." A screenshot of the top-level policy page would never show that. The phishing-resistant MFA check lines up with NIST SP 800-63B-4, which says verifiers "SHALL offer at least one phishing-resistant authentication option at AAL2." DMARC is described in RFC 7489 and SPF in RFC 7208.

Microsoft Entra ID

For OAuth, an administrator grants tenant-wide consent: sign in to the Microsoft Entra admin center as at least a Cloud Application Administrator (a Privileged Role Administrator for Microsoft Graph application permissions), find Safeguard's application under Enterprise apps and select Grant admin consent. Safeguard asks for https://graph.microsoft.com/.default and offline_access.

For the API token method, register an app under Entra ID › App registrations (single tenant), record the Application (client) ID and Directory (tenant) ID, create a client secret and copy its value at once, add the Microsoft Graph application permissions and grant admin consent. Enter the tenant ID, client ID and secret in Safeguard. The guide does not list the permission names to add. The form's optional Graph access token field mentions Directory.Read.All, but that is a short-lived token alternative to app credentials, not a statement of which application permissions the app registration needs, so confirm the exact set with Safeguard support before you grant consent. The guide flags the operational risk: client secrets expire after at most 24 months, Microsoft recommends shorter, and "collection stops when the secret expires."

The Entra ID page maps its tests to SOC 2 criteria including CC6.1 to CC6.3, CC6.6 to CC6.8 and CC7.1 to CC7.3, and to ISO/IEC 27001 Annex A controls including A.5.15 to A.5.18, A.8.2 and A.8.5. The same tests run for a connection made through Microsoft Azure or Azure Government.

Okta

Okta connects with an API token. Sign in to the Okta Admin Console as a Read-Only Administrator, ideally a dedicated service account with only that role, because "the token inherits that admin's privileges." Create the token under Security › API › Tokens, and either allow any IP or restrict it to a network zone that includes Safeguard's egress addresses. The form asks for the Okta org URL and the token.

Two notes from the guide prevent outages. Okta API tokens expire after 30 days without use, and each call resets the timer. And if the creating admin's privileges change, the token's change too. The Okta page maps its tests to SOC 2 CC6.1, CC6.2, CC6.3, CC6.6 and CC7.2, and to NIST CSF 2.0 DE.CM-03, PR.AA-01, PR.AA-03, PR.AA-05 and PR.PS-04.

Cloud infrastructure: how the accounts are configured

Cloud tests check configuration: who has admin, whether logging is on, whether storage is public. Our automated tests post walks through one CIS benchmark, so this section stays on setup and grants.

Google Cloud

Safeguard reads IAM, Cloud Storage buckets, logging, keys, networking and the other services the checks cover. One connection reads every project the credential can see, and a project it cannot read shows one error naming that project while the others still run. The Google Cloud Platform and Google Cloud Storage cards read the same API, so one connection covers both.

OAuth asks for cloud-platform.read-only and reads what your Google account can see. The guide recommends a service account for a connection that does not depend on one person. Grant these roles on each project, or once on the folder or organization above them:

roles/viewer
roles/iam.securityReviewer
roles/logging.viewer
roles/cloudkms.viewer
roles/serviceusage.serviceUsageViewer
roles/orgpolicy.policyViewer
roles/serviceusage.apiKeysViewer
roles/essentialcontacts.viewer
roles/monitoring.viewer
roles/dns.reader
roles/bigquery.metadataViewer
roles/container.clusterViewer
roles/accessapproval.viewer
roles/policyanalyzer.activityAnalysisViewer

For organization-level checks, also grant roles/resourcemanager.organizationViewer, roles/iam.securityReviewer and roles/browser on the organization.

Why the long list? roles/viewer alone lets the connection verify and list resources, but IAM policy reads, such as whether a bucket is public, need roles/iam.securityReviewer, and each other role adds the reads of one service. Google's IAM overview draws the same line: basic roles "provide broad access," while predefined roles "provide granular access for a specific service." If you grant only roles/viewer, the card can say Verified while many checks report missing permissions. The docs are explicit that a refused read "is reported as an error naming the missing permission or role, not as a failed control," so a permission gap is a setup problem, not a finding.

Amazon Web Services

AWS connects with an API token. The guide has you create a dedicated IAM user for Safeguard, create an access key for it, and attach the AWS managed policy SecurityAudit, which grants read access to security configuration metadata. AWS shows the secret access key once. The form asks for the access key ID and secret access key, with an optional region and session token.

AWS can be connected once per account, including AWS GovCloud. Each account gets its own card, every test runs against each account, and each result names the account. The AWS page maps its tests to SOC 2 criteria including CC6.1 to CC6.3, CC6.6, CC6.7, CC7.1 to CC7.4 and CC8.1, and to the CIS AWS Foundations Benchmark. Our suggestion: give the Safeguard IAM user no console access and only SecurityAudit, and rotate its key on your machine-credential schedule, so the compliance user passes the same checks it runs.

Microsoft Azure

Azure connects with OAuth (a tenant admin grants admin consent for Microsoft Graph) or app credentials: register an app in Entra ID, create a client secret, add Graph application permissions with admin consent, and assign the app a role on each subscription under Access control (IAM) › Add role assignment. The Safeguard page does not name a single Azure role. Our suggestion: start with read-only access at the subscription, and when a check reports a missing permission, grant exactly what it names.

Kubernetes connects with an API server URL and a service account token (or a kubeconfig), with get and list on RBAC objects, namespaces, nodes, pods, service accounts and network policies. Each other platform's entry in the setup reference names the vendor's own grant, for example *:read for DigitalOcean.

Source control: how code changes get made

Change management is where audits spend the most sampling effort. NIST SP 800-53 CM-3 asks you to "review proposed configuration-controlled changes to the system and approve or disapprove such changes" and to "retain records of configuration-controlled changes." For software, the record is the merge or pull request, and the control is the branch protection and approval rule that forces one. Our post on SOC 2 change management evidence for small teams covers the evidence side.

GitLab

Safeguard reads two-factor and SSO enforcement, members and administrators, branch protection, merge request approvals, pipelines and security scanning settings. There are three cards: GitLab (GitLab.com or a self-managed instance), GitLab Self-Managed, and GitLab Issues for GitLab used as a ticket tracker.

Use a personal, group or project access token with only the read_api scope. Safeguard reads every top-level group the token's user belongs to. Some reads need a role:

On a plan without a feature, the setting does not exist, and the check says so instead of failing.

Create the token under your avatar menu › Edit profile › Access tokens, or a group's or project's Settings › Access tokens. Select only read_api and set an expiry. GitLab's docs say that without a date the expiry defaults to 365 days from today. In Safeguard, choose API token, answer "Where does GitLab run?" (GitLab.com, or your instance's internet-reachable https:// address) and paste the token.

Scoping. By default Safeguard checks every project the token can read. Use Projects to include, while connecting or later on the card, to check only some. If your workspace asks for a reason when scope changes, enter one; it becomes part of the record an auditor can read. A chosen project the token cannot see is reported as an error, "never left out silently." Archived projects, forks, projects pending deletion and projects with the repository feature off are not checked by the repository tests.

What Safeguard checks in GitLab:

• Two-factor authentication required for the group, and SSO enforced
• Administrators and their number, outside collaborators, and whether admins are exempt from rules
• Default branch protection: no direct pushes and no force pushes
• Merge request approvals required, no self-approval, stale approvals dismissed, code owner review
• Required pipeline checks, and merged changes that were reviewed
• Dependency scanning alerts and their age, code scanning, and fork restrictions

One GitLab.com connection covers every group its user belongs to. Separate self-managed instances each get their own connection.

GitHub

GitHub connects with OAuth or an API token, and the difference matters. The OAuth app asks for repo, read:user and read:org, and the guide is candid that "repo grants full access to repositories, including changes; for read-only access, use the API token method with read-only permissions." An organization owner must also approve the Safeguard app under Settings › Third-party Access › OAuth app policy.

For the token, the guide offers a classic token with repo, or a fine-grained token with your organization as resource owner and read-only permissions. Our suggestion: use the fine-grained read-only token. It matches the read-only principle of the rest of the catalogue, and it is the version your auditor will be happiest to read about. The GitHub page maps its tests to SOC 2 criteria including CC6.1 to CC6.3, CC7.1 to CC7.5 and CC8.1, and to ISO/IEC 27001 controls including A.8.4, A.8.25, A.8.28, A.8.29 and A.8.32. GitHub Enterprise connects to the same provider.

Bitbucket

Bitbucket connects with OAuth (Safeguard asks for repository and account) or a token. Safeguard's docs describe the token two ways. The setup steps describe a Bitbucket Cloud API token with the read-only scopes read:user:bitbucket, read:workspace:bitbucket and read:repository:bitbucket, while the connect form asks for your Bitbucket username (not your email), puts the credential in a field labelled App password, and says to create it with read-only Account, Workspace membership and Repository scopes. Follow the help text on the form you are looking at, keep every scope read-only, and ask Safeguard support if the credential you created is refused. The workspace field is optional. If you leave the workspace blank, Safeguard uses the first workspace the credential can see, so fill it in.

Ticketing: incidents, security issues and offboarding

The ticket tracker is where operating effectiveness lives. A policy that says "critical security issues are fixed within a time limit" is tested by the tickets. NIST SP 800-53 IR-4 covers incident handling, and PS-4 says that upon termination you "disable system access within" a defined time and "terminate or revoke any authenticators and credentials associated with the individual." The ticket is your evidence that someone did it, and when.

Jira

Safeguard reads Jira Cloud with read access: security, incident, offboarding and post-mortem tickets, their priority, assignee, status and resolution dates, issues linked to incidents, and the site's user accounts for access reviews. Jira Cloud only; Data Center and Server are not supported.

With OAuth, Safeguard asks for read:jira-work and offline_access. Atlassian describes read:jira-work as "Read Jira project and issue data, search for issues and objects associated with issues like attachments and worklogs." An OAuth connection reads up to three Jira sites your Atlassian account can reach, as your account. With an API token, create it at id.atlassian.com under Security › API tokens as the account Safeguard should read as, one that can browse the projects holding security and incident tickets, and enter its email, the token and your site URL. Jira can be connected once per site.

What Safeguard checks in Jira. It finds tickets by label or issue type (security, incident, offboarding, post-mortem) that are open or recently resolved, then checks:

• Security issues are assigned, and the highest-priority ones are resolved within their time limit
• Incidents have their follow-up work closed, and a post-mortem
• Every departure has an offboarding ticket
• Jira accounts belong to people in your personnel register, and people who left no longer have access (bots and service desk customers are left out)

A ticket counts as resolved at its resolution date or, in a workflow that sets none, when it moved to a Done status. Our suggestion: agree the labels with the teams that file tickets before you connect. If nobody labels incidents consistently, the check has nothing to find, and an empty result reads very differently to an auditor than "no incidents." See incident response evidence when you had no incidents.

ServiceNow

ServiceNow connects with an API token and a least-privilege service user. As an administrator, create a user under All › User Administration › Users, check "Web service access only" so it is non-interactive, set a password, and add roles giving read access to six tables: incident, problem, sc_req_item, change_request, sys_user and sys_user_has_role. The guide notes that ServiceNow's docs name no single built-in role for exactly those tables, so a custom role with read ACLs on them is the least-privilege option.

The form takes the instance URL (an address under service-now.com), username and password, or an access token instead; the form marks these fields optional, though a connection needs a way to sign in. The ServiceNow page maps its tests to SOC 2 criteria including CC6.2, CC6.3, CC7.1, CC7.3 to CC7.5 and CC8.1, and to ISO/IEC 27001 controls including A.5.25 to A.5.27 and A.8.32. Because change_request is in scope, ServiceNow can feed change management evidence as well as incidents.

Other trackers in the Ticketing category have their own forms. Zendesk and Smartsheet need an administrator credential because they show the full user list only to administrators, and Trello needs its Enterprise plan.

The personnel register, and why HR systems are on the list

Several checks compare accounts against people. "Jira accounts belong to people in your personnel register" only works if the register is current. An HRIS connector such as BambooHR syncs people, employment status, start dates and end dates into the register. Its key needs a user who can see every employee, with access to workEmail, hireDate, supervisorEId and employmentHistoryStatus.

That is the join that makes leaver evidence work. HR records an end date, the register knows the person left, the next identity run checks whether their account is still active, and the next Jira run checks access and the offboarding ticket. Our same-day offboarding test and access reviews posts show how auditors sample this.

The grant cheat sheet

One table to hand to each system's owner. The grants come from the Safeguard connector pages; the last column is our suggestion.

How the evidence maps to frameworks

Every connector page has a Frameworks table listing the control identifiers its tests map to. That table answers the auditor's question "where does this evidence come from?" Examples as the docs list them:

SOC 2 reports use the AICPA's 2017 Trust Services Criteria, with revised points of focus published in 2022. The identifiers above are Safeguard's mapping, not your auditor's opinion. The auditor decides whether a test result is enough for a criterion in your environment, and some criteria always need a policy, a meeting record or an attestation alongside.

If you also track NIST SP 800-53, here is our suggested crosswalk for the connector families in this post. It is a starting point for your control matrix, not an official mapping:

Choose what each connector collects

Two connectors can often answer the same question: MFA from Google Workspace and from Okta, users from the identity provider and from Jira. The What this connector collects panel, on the connect form and the connected card, lists every test and evidence check that reads from a connector, each with a switch. Switch one off and another connector can still supply it. Only the person who connected it or an administrator can change these switches. If your workspace starts new connectors with everything off, turn on at least one check before you connect.

Our suggestion: pick one system of record per question and write it in your control narrative. "MFA enforcement evidence comes from the Okta connector" is a sentence an auditor can test. Two sources that disagree cost an afternoon of fieldwork.

Keeping connections healthy

A connector that stopped working three months ago is worse than none, because the gap shows up exactly when the auditor samples that quarter.

Admins can Re-check one connection or all of them, and Collect evidence now starts a collection immediately. On a connected card, Test connection asks the provider whether the credential still works, Reconnect takes a new credential after a rotation, Re-authorize reruns the sign-in, and Rename changes the label that tells accounts apart. Disconnect clears the credential, stops the tests and keeps earlier results as history. Remove deletes the connector entirely. Our suggestion: when you retire a system mid-period, Disconnect it, and Remove only after the audit period that covered it has closed.

Several accounts. AWS (including GovCloud), Google Cloud, Microsoft Azure (including Azure Government), OVHcloud, GitLab Self-Managed and Jira, among others, can be connected once per account with Add another account. Label each one, such as "Production" and "Staging". An account you forget produces no evidence and no error, so reconcile the cards against your cloud account inventory each quarter.

Schedules and new tests. Tests run on a schedule about every six hours, each as often as it is due, daily by default. Run now or Run all tests on Compliance › Tests runs them sooner. A newly added test does not count straight away: for its first period, typically 14 days, its results show on the Tests page but do not change any control's status or your readiness score, and open no tasks. Connect a new system at least two weeks before the period you need it for.

An expiry calendar.

A walkthrough: the first week

Our suggested order for a GRC lead and one engineer, assuming your frameworks are already chosen as in work toward SOC 2 with the compliance suite.

1. Day 1, access and inventory. Switch off unused categories under Settings › Connector access. List every in-scope system with its owner, accounts and chosen method.
2. Day 2, identity. Connect HRIS first so the personnel register is populated. Then connect Google Workspace with domain-wide delegation, Entra ID with an app registration, or Okta with a Read-Only Administrator token. Confirm Verified and set the collection switches.
3. Day 3, cloud. Connect Google Cloud with roles at the organization or folder, each AWS account with its own label, and Azure with a role on each subscription. Use Collect evidence now and fix every "missing permission" error, then Re-check.
4. Day 4, source control. Connect GitLab with a read_api group token at Developer, or GitHub with a fine-grained read-only token. Set Projects to include if only some repositories are in scope, and confirm branch protection and approval checks return results.
5. Day 5, ticketing and review. Agree ticket labels, connect Jira or ServiceNow with a dedicated read account, then Run all tests and read the first failures with their owners. Our triage post covers how. Add every credential's expiry to the compliance calendar.

What an auditor will ask about each source

Where Safeguard fits, and where it does not

Connectors remove the busywork of collecting configuration and ticket evidence. They do not replace the human parts of a control. A connector can show that MFA was enforced every day of the period; it cannot show that the access review meeting made sensible decisions. The setup reference is open about this: for one domain registrar it notes that the API does not show the account's two-factor authentication or who can sign in, "and the other two are attested." Expect a mix of automated and attested evidence, and use connectors to make the automated share as large as your systems allow.

For the compliance tool itself, your auditor and customers will ask how it is secured. Safeguard is SOC 2 Type I and Type II audited, and its SaaS regions are US, EU (Frankfurt, Germany) and Gov.

Common mistakes

• Connecting with a personal account. The evidence stops when that person leaves, and the token carries their full permissions.
• Granting only roles/viewer in Google Cloud. The card says Verified, but IAM policy reads need roles/iam.securityReviewer.
• Using GitHub OAuth for convenience. The repo scope grants full access including changes.
• Expecting device evidence from the Google sign-in. Endpoint management checks need the service account.
• Forgetting a second cloud account. An unconnected account produces no evidence and no error.
• No agreed ticket labels. Jira checks find tickets by label or type; without them, an empty result looks like nothing happened.
• Connecting days before the audit window. New tests take typically 14 days to count toward controls.
• Letting a client secret expire. Entra ID collection stops when it does.
• Removing a retired connector mid-period. Disconnect keeps the history; Remove deletes the connector.

FAQ

Which systems can feed evidence into Safeguard automatically?

Identity providers, cloud accounts, code hosts, ticket trackers, HR systems and many other categories, all under Compliance › Connectors and in the docs' connector setup reference. Each connector's page says what a connection produces.

Does Safeguard change anything in my systems?

No. Every guide asks for the narrowest read-only grant the vendor offers, and Safeguard only makes read calls, including with the few vendors that issue no read-only credential.

Should I use OAuth or an API token?

OAuth for a quick, revocable setup where the vendor offers a read scope. An API token for a stable service identity, or where the connect form says the tests need it.

What is the MCP server method for?

It connects the vendor's MCP server so Search can call the connector's tools and you can ask Griffin, Safeguard's security model, about the system. It does not feed compliance tests.

How often does Safeguard collect evidence?

Tests run about every six hours, each as often as it is due, daily by default. Run now and Collect evidence now trigger a run immediately.

Why does a new connection show Verified but no results?

Verified means the provider accepted the credential. Tests still need to run, and newly added tests take typically 14 days before they change control status.

Can I connect several AWS accounts or Jira sites?

Yes. Several providers can be connected once per account or site; each gets its own card and each result names the account.

Does a passing test mean my SOC 2 control is met?

No. It is evidence toward a control, not proof on its own. Your auditor decides, and some criteria also need policies, records or attestations.

Keep the code behind your controls current

Change management evidence from your code host shows that changes were reviewed. It does not show that the open source packages those changes pulled in were safe, and vulnerability management is its own control in every framework above.

Fix it without waiting for upstream

Whatever the vulnerability, most of the risk sits in two gaps. The first is the time between a fix being published and that fix actually running in your production builds. The second, and worse, is the time before any fix exists at all, while a maintainer works out a patch and a release schedule. Waiting through both gaps is a habit, not a requirement. Safeguard gives teams three ways to close them.

1. Autonomous remediation: pull requests, not tickets

When a fixed version exists, Griffin, Safeguard's security model, opens a policy gated pull request that moves the affected dependency to the safe version, and your own CI runs your tests on it before anyone merges. You can run it on one repository or in bulk across every project that carries the vulnerable version. Remediation categories include dependencies, licenses, security posture and findings, and each one is set separately. Reachability analysis ranks the vulnerable code paths your application actually calls first, so the first pull requests you merge are the ones that matter most. Auto-merge is a separate switch and stays off by default, so your team decides what merges on its own and what still needs a human approval.

2. Gold Open Source: the safe version in seconds, free

gold.safeguard.sh is free and needs no login. Search any CVE or package to see affected and fixed versions, CVSS, EPSS, CISA KEV status and a recommended safe version, or use the "Am I affected?" checker. The same data is available through a free read API, README status badges and RSS threat feeds.

3. Gold Registry: start from components that are already fixed

Safeguard Gold rebuilds patched versions of open-source packages and images from source, signs each build, attaches an SBOM, SLSA provenance and VEX, and serves them from registry.safeguard.sh to your organization. Every Gold artifact is held continuously to zero exploitable critical or high CVEs and a completed license check, with signed build provenance (signed with Safeguard's key and verifiable with cosign, SLSA Build Level 3 as the design target) and a public evidence page you can hand to an auditor. An artifact loses its Gold badge if it regresses. Teams can point their own package directory at the registry so hardened equivalents resolve without changing how developers install anything.

When upstream has no fix yet, or will not ship one, Safeguard first works to get the fix accepted upstream. If the issue is severe or upstream will not move, Safeguard builds a fork, fixes the vulnerability there and publishes a hardened Gold build, so you are not stuck on a maintainer's release schedule. You can also request a hardened build of a specific package. Ask which packages it covers before you plan around it.

One honest limit: when the vulnerable code lives in a vendor appliance, a hosted service or an operating system runtime you do not build yourself, the fix still has to come from that vendor or distribution. The steps above apply to the open source dependencies and container images you build and ship, which is where most teams carry the largest and least tracked share of their exposure.

See how Safeguard would help

Connectors are set up in the web app. These demos show the flows around them: an assistant reading Safeguard data with the tools you allow, a policy-gated fix pull request that closes a finding, and approving work from a phone.

This demo connects Claude to the Safeguard MCP server with OAuth and lets you choose which tools Claude can use. A GRC lead can use the same pattern to have an assistant summarise which controls have failing tests before a review meeting, while the connectors keep collecting in the background.

Click through it at your own pace, or open it full screen.

In this real CLI session you run safeguard to open the interactive terminal and ask it to fix a lodash CVE. It reads the finding and advisory, asks before any command that changes something, edits package.json to lodash 4.17.21, runs npm install and npm test with approval, prints a summary and pushes nothing. The change then goes through the same reviewed merge request that your code host connector records as change management evidence.

Click through it at your own pace, or open it full screen.

This is a real Android session: work is sent to a computer running the Safeguard CLI, and the command is approved on the phone with Allow once, Allow for turn or Deny. When a failing control needs a fix and its owner is away from a desk, the approval still has a named person behind it.

Click through it at your own pace, or open it full screen.

To try it on your own projects, download Safeguard or read the CLI docs.

Quick check

Sources

• Safeguard docs: Compliance connectors
• Safeguard docs: Connector setup reference
• Safeguard docs: Google Workspace connector
• Safeguard docs: Google Cloud connector
• Safeguard docs: Jira connector
• Safeguard docs: GitLab connector
• Safeguard docs: Amazon Web Services connector
• Safeguard docs: Microsoft Azure connector
• Safeguard docs: Microsoft Entra ID connector
• Safeguard docs: Okta connector
• Safeguard docs: GitHub connector
• Safeguard docs: Bitbucket connector
• Safeguard docs: ServiceNow connector
• Safeguard docs: BambooHR connector
• AICPA: 2017 Trust Services Criteria (With Revised Points of Focus, 2022)
• NIST SP 800-53 Rev. 5: Security and Privacy Controls for Information Systems and Organizations
• NIST SP 800-137: Information Security Continuous Monitoring
• NIST Cybersecurity Framework 2.0 (CSWP 29)
• NIST SP 800-63B-4: Authentication and Authenticator Management
• Google Workspace Admin Help: Control API access with domain-wide delegation
• Google Cloud: Roles and permissions overview
• GitLab docs: Personal access tokens
• Atlassian: Scopes for OAuth 2.0 (3LO) and Forge apps
• RFC 7489: Domain-based Message Authentication, Reporting, and Conformance (DMARC)
• RFC 7208: Sender Policy Framework (SPF)

Last reviewed: 28 October 2026. Product behaviour is described from Safeguard's public docs; check the linked pages for changes.