Audit-ready evidence for every change, without the spreadsheet

MergeHarbor records who approved each pull request, what was checked and how every finding was resolved, checks it against your policies, and seals it when it merges. Your auditors get a population, a reproducible sample and a hash-verified archive.

What each pull request's evidence contains

Assembled from MergeHarbor's review records and your code host. Nothing for engineers to fill in.

Who: Who opened the change, who approved it on the code host and on which commit, and who merged it.
What was checked: Every MergeHarbor review of the change: its depth, the models used, the categories, built-in checks and rules in force.
What was found: Every finding, and how it ended: fixed in a later commit, marked addressed, or dismissed with a reason and a name.
Proof: Generated tests that tried to reproduce findings, and whether linked tickets' acceptance criteria were met.
The verdict: Pass or fail for each of your controls, with the reason for every check, and any exception with its justification.

From policy to sealed record

Write policies as code

Start from SOC 2, ISO 27001 or PCI DSS starter packs, then add your own controls in YAML: required approvals, security review for sensitive paths, no open critical findings, rollbacks for migrations.

See it before the merge

Every open pull request shows which controls pass and which still fail, so authors fix gaps before the change lands, not during the audit.

Sealed at merge

Evidence is sealed into an append-only, hash-chained ledger. Accepted exceptions are recorded next to it with a justification and a name.

Your controls, versioned and reviewable

Policies live in the console, with every saved version kept and hashed. Repositories can add stricter policies in their configuration file; they cannot weaken yours.

policies:
  - id: payments-security-review
    name: Security review for payment code
    applies_to:
      branches: [$default]
      paths: ["payments/**"]
    require:
      - review_completed: {min_tier: deep}
      - approvals: {min: 1, from_teams: [security]}
      - no_open_findings: {min_severity: major}
    frameworks:
      pci_dss: ["6.2.4"]

Starter packs mapped to the requirements you report against

References show which requirements the evidence helps support. They are not a certification, and your auditor decides what each control needs.

Control	SOC 2	ISO/IEC 27001:2022	PCI DSS v4.0
Peer approval before merge	CC8.1	A.8.32	-
Independent approval of the final change	-	-	6.2.3.1, 6.5.1
Automated review of the final change	CC8.1	A.8.29	6.2.3
No unresolved critical findings	CC7.1, CC8.1	-	6.2.3
Security findings resolved	CC7.1	A.8.28	6.2.4
No hard-coded secrets	CC6.1	A.5.17	8.6.2
Back-out plan for database migrations	CC8.1	A.8.32	6.5.1

Reports your auditor can test

Complete population

Every pull request merged in the period, with its evidence status.

Reproducible sample

A random sample with a recorded seed and a documented method.

Control results

Per-control results and every accepted exception with its justification.

Verifiable archive

CSV, JSON and PDF, with a signed manifest of SHA-256 hashes.

Frequently asked questions

Does using MergeHarbor make us SOC 2, ISO 27001 or PCI DSS compliant?

No. Compliance depends on your whole program and your auditor's judgment. MergeHarbor produces evidence for the change-management controls you define and shows which framework requirements each control helps support. It is not a certification of your organization or of MergeHarbor.

How do auditors know the evidence was not edited?

Each pull request's evidence is sealed when it merges into an append-only ledger. Every record carries the SHA-256 hash of the one before it, so changing, removing or reordering a record breaks the chain, and anyone with access can re-verify it. Exceptions are separate records and never change sealed evidence. Report archives list the SHA-256 of every file and carry MergeHarbor's signature.

Can an engineer weaken a policy in their repository?

No. Repositories can add policies in their configuration file, read from the base branch, but cannot turn off or replace the organization's policies.

How is the sample chosen?

Randomly, from every change merged in the period, with a seed that is recorded in the report. The method is written in the report's manifest, so your auditor can draw the same sample again from the population file.

Which code hosts are supported?

Approvals and the merger are read from GitHub and GitLab. On other code hosts the evidence says approvals are unavailable, and approval controls fail rather than pass silently.

Have another question? Talk to our team

Make your next change audit routine

Compliance evidence is part of the Advanced and Enterprise plans, in MergeHarbor cloud or, on Enterprise, self-hosted.