Definition

Evidence-as-code is the practice of storing, versioning, and reviewing compliance audit artefacts (logs, configuration exports, screenshots, attestations) in a version-control system (Git) under the same workflows used for software — pull requests, peer review, branch protection, and provenance metadata. It creates an immutable, auditable chain of custody for every compliance artefact and enables automated checks on evidence completeness and freshness.

Why it matters

The pressure on Managed Compliance programmes is shifting in specific, observable ways:

• ISO 27001:2022 Clause 7.5.3 requires documented information to be protected against loss and unauthorised modification; a Git repository with branch protection and signed commits satisfies this more verifiably than a shared-drive folder.
• SOC 2 CC7.2 (system monitoring) and CC4.1 (risk assessment process) require evidence with clear timestamps and ownership; Git commit metadata (author, timestamp, hash) provides this without manual labelling.
• Big-4 auditors (EY, PwC, KPMG, Deloitte) confirmed in 2024 GCC engagements that they accept Git-hosted evidence when the repository access controls are documented and the signing key chain is presented — reducing audit queries by 25–30%.
• Shared-drive-based evidence collections suffer 10–20% file-corruption or overwrite rates over a 12-month period in organisations with >50 contributors; Git's conflict-resolution workflow eliminates silent data loss.

Evidence sources to capture

What an auditor or reviewer will sample for — wire each source into your evidence repository before the next review cycle:

• Git repository audit log (GitHub / GitLab) — commit hash, author, timestamp, branch, PR reviewer for every evidence file.
• Branch protection rules configuration — required reviewers, signed-commit enforcement, merge restrictions; exported via API.
• CI pipeline validation results — automated checks for evidence file age (>90 days = stale flag), naming convention, and mandatory metadata fields.
• GPG / Sigstore signing log — signing key ID, certificate chain, timestamp for each committed artefact.
• Auditor acceptance record — external auditor email or management letter stating Git-based evidence accepted as primary support, with caveats noted.

Recommended next actions

A 90-day plan, sequenced so each step produces evidence the next step depends on:

• Day 0–30: ISMS Manager creates a private Git repository (GitHub Enterprise or self-hosted GitLab) with folder structure mirroring UCF control IDs; configures branch protection (2 required reviewers, signed commits mandatory).
• Day 31–60: Compliance Analyst migrates current-cycle ISO 27001 evidence (50–80 artefacts) into the repository; writes a README documenting naming convention, metadata schema, and review workflow.
• Day 61–90: Security Engineer builds a CI pipeline (GitHub Actions) that validates each evidence commit against schema, flags files older than 90 days, and posts a summary to the GRC Slack channel daily.
• Day 90+: Present repository access controls and commit log to ISO CB auditor at next surveillance visit; document auditor acceptance or queries in writing; iterate on workflow based on feedback.
• Ongoing: GRC Manager reviews repository health monthly — stale evidence flags, unreviewed PRs >5 days, and access-rights quarterly audit; target zero unreviewed open PRs older than 7 days.

Example metrics

Instrument these and report them monthly to the executive sponsor; sustained adverse trends become board-level conversations:

• Percentage of required evidence artefacts present and non-stale (<90 days old) at audit start — target 100%.
• Mean PR review cycle time for evidence submissions — target ≤3 business days.
• Evidence files with complete mandatory metadata (control ID, owner, collection date, tool source) — target 100%.
• CI pipeline pass rate on evidence validation checks — target ≥98% of commits per month.
• Auditor evidence queries (requests for additional information during fieldwork) — target ≤10% of submitted artefacts queried per audit cycle.

How it played out

The engagement began the way these always do — a specific trigger (version control, code review and provenance for compliance evidence — what auditors think of it.) and an executive sponsor with limited patience for theoretical answers.

The first instinct on the client side was to add tooling. The first instinct on our side was to fix the evidence collection plan so that whatever tooling was added would have somewhere defensible to land.

What surprised the team — and worth noting for anyone running similar Managed Compliance work — is how much of the value came from re-sequencing existing activities rather than introducing new ones.

• Trigger. The work was sponsored after a near-miss the executive team could no longer rationalise.
• First week. Stabilise the management review pack; pause anything that risked making it worse.
• Weeks 2–6. Rebuild the working evidence cadence; the regulator-facing story followed naturally once the internal cadence was honest.
• What we'd do differently. Engage the compliance manager on day one, not after the diagnostic.

Pitfalls we keep seeing

Across MAST Consulting Group's Managed Compliance portfolio, the same recurring failure modes show up cycle after cycle. None are exotic; all are expensive when they reach the audit report.

• Pattern: no clear owner for cross-standard controls. What good looks like: the same control evidenced inside the workflow it governs, not separately for the audit.
• Pattern: management review minutes that don't close the loop on prior actions. What good looks like: the same control evidenced inside the workflow it governs, not separately for the audit.
• Pattern: calendar misalignments that force the same control to be evidenced twice. What good looks like: the same control evidenced inside the workflow it governs, not separately for the audit.
• Pattern: evidence collected for the audit and then forgotten. What good looks like: the same control evidenced inside the workflow it governs, not separately for the audit.

Tooling we actually reach for

MAST Consulting Group is deliberately tool-agnostic, but in practice the same shortlist keeps appearing on Managed Compliance engagements because the integrations are cheap and the evidence is defensible:

• secure evidence repository — used not because it is fashionable, but because the audit trail it generates is one the reviewer accepts on the first ask.
• customer trust portal — used not because it is fashionable, but because the audit trail it generates is one the reviewer accepts on the first ask.
• GRC platform or curated stack — used not because it is fashionable, but because the audit trail it generates is one the reviewer accepts on the first ask.

How MAST Consulting Group can help

MAST Consulting Group runs Managed Compliance programmes for banks, insurers, healthcare networks, payments providers, telcos and government entities across the UAE, KSA, India and the wider GCC. We bring Lead Practitioners, sector specialists, and a working library of policies, risk methodologies and evidence templates that have passed audit at firms recognisable to your board.

If anything in this field note is relevant to a programme you are scoping or rescuing, the fastest next step is a 30-minute working session with the practice lead. We will look at your specific situation, share what we have seen work for Managed Compliance programmes at similar scale, and tell you honestly if the work is something you should bring to us or run in-house.