Veritrail documentation

Introduction

Veritrail collects auditor-ready technical evidence for SOC 2, ISO 27001, and the CIS AWS Foundations Benchmark from your cloud accounts, source-control organizations, and identity providers. It connects read-only, scans continuously, maps findings to the controls they support, and produces signed evidence packs on demand.

Veritrail is an evidence platform — it collects and shows the state of your infrastructure and change process. It scans and reports; it does not modify your environment. Every finding ships with console and CLI remediation guidance, and a Verify fix re-check confirms the fix once you have applied it yourself.

Quickstart

From a fresh workspace to your first evidence pack:

1. Sign in at app.veritrail.io and create your workspace.
2. On Home, add an AWS account with the read-only connector role (see Connect AWS).
3. Run a scan, or wait for the daily scan to complete.
4. Review organization readiness on Home, findings on Findings, and control coverage on Compliance.
5. Export an evidence pack from Compliance → Generate audit package.

Optionally connect GCP, Azure, GitHub, GitLab, Microsoft Entra ID, or Google Workspace to widen coverage.

How it works

Veritrail runs three things continuously:

Cloud findings are scoped to the account they came from. Source-control and identity-provider evidence is organization-level and updates when you sync those integrations — no cloud scan required. The Findings page lets you filter by a single account or by org-wide scope: all cloud accounts, source control, or identity.

When you fix an issue, use Verify fix on the finding to re-check just that item — it works for account-scoped cloud findings and for org-level GitHub, GitLab, and identity findings alike. The History page keeps point-in-time compliance snapshots, and prior audit packages can be downloaded from there.

Workflow integrations are optional: connect Jira to turn findings into tracked remediation tickets, and Slack for scan alerts and weekly digests.

Connect AWS

Veritrail assumes a read-only role in your account via CloudFormation. The stack creates a role Veritrail can assume with an ExternalId — no long-lived keys.

1. In the app, go to Home → Add account and choose AWS.
2. Deploy the provided CloudFormation stack — the app gives you a one-click launch URL and an equivalent aws cloudformation CLI command. The ExternalId is generated when you start the connection and is pre-filled as a stack parameter.
3. Paste the role ARN back into Veritrail and verify the connection.
4. Run your first scan.

The scanner role is read-only: it grants describe/list/get permissions only, with no write access and no PassRole. You can review the full IAM action list in the app before deploying the stack.

Connect Google Cloud

Veritrail reads GCP configuration through a scanner service account in your project, accessed via service-account impersonation — no exported keys.

1. Go to Home → Add account and choose Google Cloud, then follow the gcloud setup shown in the app.
2. Grant the scanner service account the read-only roles Veritrail requests: roles/viewer, roles/logging.viewer, roles/osconfig.viewer, roles/securitycenter.findingsViewer, and roles/cloudasset.viewer. Veritrail's platform service account needs roles/iam.serviceAccountTokenCreator on the scanner service account.
3. Verify and run a scan.

This covers project inventory, logging configuration, Security Command Center findings, and asset IAM checks — all read-only.

Connect Azure

Veritrail connects to Azure through an app registration with Reader and Security Reader roles on the subscriptions you want covered.

1. Go to Home → Add account and choose Azure.
2. Register the app and assign the two read-only roles to the target subscriptions.
3. Enter the client credentials, verify, and scan.

Coverage includes Microsoft Defender posture, storage configuration, Resource Graph inventory, Activity Log, privileged RBAC assignments, and Azure Policy compliance.

Connect GitHub & GitLab

Source control provides change-management evidence: branch protection, required reviews, org MFA posture, and collaborator access. These checks are organization-level and run when you sync the integration — they are not tied to a cloud account.

1. Go to Integrations → GitHub (or GitLab) and authorize with OAuth. GitHub requests read:user, user:email, read:org, and repo; GitLab requests read_api.
2. Select the organization (or GitLab group) to collect from.
3. Sync — findings appear org-wide and grade your change-management controls immediately.

After you fix an issue in GitHub or GitLab — say, enabling branch protection — use Verify fix on the finding to re-check it without waiting for the next sync.

Connect Microsoft Entra ID

Entra ID supplies access-management evidence — directory users, MFA enforcement, and privileged role assignments — for your logical-access controls.

1. Go to Integrations → Microsoft Entra ID.
2. Complete the OAuth connection. Veritrail requests read-only delegated scopes: User.Read, Directory.Read.All, and RoleManagement.Read.Directory (plus offline_access to keep the sync running).
3. Sync. Identity findings are organization-level and update compliance without a cloud scan.

Connect Google Workspace

Google Workspace supplies directory and admin-governance evidence: workspace users, 2-Step Verification enforcement, and admin role review.

1. Go to Integrations → Google Workspace.
2. Complete the OAuth connection as a Workspace administrator. Veritrail requests read-only scopes: admin.directory.user.readonly and admin.directory.rolemanagement.readonly.
3. Sync. Findings are organization-level, same as Entra ID.

Controls & mapping

Every check maps to the framework controls it supports. On the Compliance page, controls are grouped into capability domains — logical access, change management, logging & monitoring, data protection, and more.

• Failing — Veritrail evaluated the control and found an issue. The finding is shown with remediation guidance.
• Coverage gap — the evidence lives outside what a connected scan can see (for example, HR or vendor records). Attach external evidence to close it.

Open findings and accepted risks are kept distinct: a finding you have risk-accepted with a recorded reason becomes a documented exception and no longer fails the control, while any open finding is treated as a gap. Both appear, clearly separated, in evidence packs and the narrative report.

When a required service is off — say VPC flow logs or a threat-detection service — Veritrail shows it as a finding with a direct link to enable it, because turning it on is what lets Veritrail grade the control.

Evidence packs

An evidence pack is a point-in-time ZIP export of your control coverage and the findings behind it, for a chosen framework and evidence window. Generate one from Compliance → Generate audit package.

Every item in a pack traces back to the source it was collected from, with a timestamp.

Verifying pack integrity

Anyone holding a pack — including your auditor — can verify it without a Veritrail account:

1. Verify the download. The pack's SHA-256 is shown at download time (and sent in the X-Veritrail-Pack-SHA256 response header). Compare it against shasum -a 256 pack.zip.
2. Verify the contents. checksum_manifest.json lists a SHA-256 hash for every file in the ZIP except itself. Recompute and compare.
3. Verify the signature. When signing is configured, pack_signature.json contains an Ed25519 signature over the exact bytes of checksum_manifest.json. Check that payload_sha256 matches the manifest's SHA-256, then verify signature_base64 against public_key_base64. The public key is also published at GET /v1/meta/evidence-pack-signing-key for independent confirmation.

Narrative PDF report

The PDF inside each evidence pack is written for the auditor reading it, not as a raw finding dump. Evidence is grouped into capability domains, and each domain section contains:

• An assertion paragraph — affirmative but evidence-anchored and scoped to what was actually observed.
• A coverage line stating what was evaluated and over what window.
• Documented exceptions — risk-accepted deviations with their recorded reasons — listed separately from open gaps.
• Framework cross-reference tags tying the domain back to SOC 2, ISO 27001, and CIS AWS control IDs.

Per-resource detail lives in Appendix A at the back of the document, with each row marked as an open gap or a documented exception. The complete enumerated population always lives in each control's findings.json and exceptions.json inside the pack — the PDF references it rather than truncating silently.

Auditor portal

Instead of emailing files, you can share a read-only auditor portal. From Workspace → Sharing, invite your auditor by email and set an expiry. They receive a tokenized sign-in link — no Veritrail account required — to a scoped view of findings, controls, and evidence. They get no access to your workspace settings or your connected accounts.

• Auditors can download evidence pack ZIPs directly, with the integrity panel showing the pack's SHA-256 and signature-verification instructions.
• You can generate scoped, time-limited download links for prior exports.
• Grants can be extended or revoked at any time.

Trust Center

Separately from the auditor portal, you can publish a public Trust Center at /trust/<your-slug> — a customer-facing page listing your frameworks and security documents, with an access-request form. Configure it under Workspace → Sharing.

Scheduled exports

Rather than remembering to export before an audit, you can have Veritrail build evidence packs on a schedule so your audit window is continuously covered.

1. Enable scheduled exports in Workspace settings.
2. Choose the framework (SOC 2, ISO 27001, or CIS AWS), the evidence window (7–365 days; 90 by default), and the cadence (weekly or monthly).

Each run builds a pack per connected account covering the chosen window, and optionally emails you when it completes. Scheduled packs appear in your export history alongside manual ones, ready to download or share through the auditor portal.

Security & access

FAQ

Do I need to install anything in my environment?

No. Veritrail collects through cloud and provider APIs — there are no agents to deploy. The only in-account artifact is the read-only IAM role (AWS) or service account (GCP) you create during connection.

Which frameworks are supported?

SOC 2, ISO 27001, and the CIS AWS Foundations Benchmark. Findings map to the controls they support in each.

Does Veritrail change anything in my accounts?

No. Veritrail is scanning-only. Findings come with console and CLI remediation guidance, and once you apply a fix yourself, Verify fix re-checks that finding on demand.

Does Veritrail make my company audit-ready on its own?

No — Veritrail covers the technical evidence: infrastructure, identity, and change management. Policy and HR evidence is attached alongside it in the Compliance workspace, and shows up as coverage gaps until you attach it.

Can I feed the evidence into Vanta or Drata?

Direct destinations for Drata, Secureframe, Sprinto, and Vanta are coming soon. Today, every evidence pack includes machine-readable JSON and CSV you can import into your GRC platform.

Where can I see the exact permissions each integration uses?

The in-app reference at app.veritrail.io/reference lists the auth method and the exact scopes or roles per integration, plus search keys for the Findings page.