Tech Due Diligence CQ-8: Version Control and Branching Strategy
What This Control Requires
The assessor evaluates version control practices, including the branching strategy, commit hygiene, repository organisation, and the ability to trace changes back to requirements or issues.
In Plain Language
Your Git history is a permanent record of how your team actually works. Assessors read it closely, and it tells them more than most teams realise. They will check whether you follow a clear branching strategy consistently, whether commits are atomic and well-described, whether changes trace back to tickets or requirements, whether the repository is well-organised with clear module boundaries, and whether anyone has ever committed secrets to the repo. A chaotic history with large undescribed commits, direct pushes to main, and no traceability suggests ad-hoc engineering. A clean history with meaningful messages, consistent branching, and issue references signals a disciplined team that will hold up as it scales.
How to Implement
Pick a branching strategy that fits your team and deployment model, and document it. Trunk-based development with short-lived feature branches works well for teams with mature CI/CD. GitFlow suits teams managing multiple release versions. Whatever you choose, the whole team needs to follow it. Set commit message conventions. A structured format like Conventional Commits (feat:, fix:, refactor:, docs:) enables automated changelog generation and semantic versioning. Require that every commit references the relevant issue or ticket number. Configure branch protection rules: require PR review before merging to main, require CI checks to pass, prevent force-pushing to main or release branches, and require signed commits in high-security environments. Keep Git history clean. Squash-merge feature branches into a single well-described commit, or make sure individual commits on feature branches are meaningful and atomic. Organise your repositories logically. For monorepos, maintain clear directory structures with module boundaries. For multi-repo setups, define ownership and dependency relationships. Document the structure either way. Scan for accidentally committed secrets using tools like git-secrets, truffleHog, or GitGuardian. Add pre-commit hooks that block secret commits before they reach the remote. Review repository access controls regularly. Limit write access to active team members, audit access periodically, and keep logs of who changed what. Maintain a consistent tagging and release strategy so you can always identify which code is running in production. Tag releases and keep release notes up to date.
Evidence Your Auditor Will Request
- Documented branching strategy
- Branch protection configuration
- Sample Git history showing commit quality and traceability
- Repository access control configuration
- Secret scanning tool configuration and historical scan results
Common Mistakes
- No consistent branching strategy; developers use ad-hoc approaches
- Commits are large and undescribed, making it impossible to understand change history
- Secrets (API keys, passwords) found in Git history
- Direct pushes to main branch without review
- No connection between commits and issues/requirements; poor traceability
Related Controls Across Frameworks
| Framework | Control ID | Relationship |
|---|---|---|
| ISO 27001 | A.8.4 | Related |
Frequently Asked Questions
What if secrets were committed historically but have since been rotated?
Is monorepo or multi-repo preferred?
Track Tech Due Diligence compliance in one place
AuditFront helps you manage every Tech Due Diligence control, collect evidence, and stay audit-ready.
Start Free Assessment