How do you set up Azure DevOps for compliance — audit logs, branch protection, required reviewers, and approval gates?

Think of setting up Azure DevOps for compliance like designing the security system for a pharmaceutical clean room. Every person entering is logged (audit), the airlock requires two-person authorization before opening (required reviewers), the manufacturing equipment only activates after quality control signs off (approval gates), every batch has a traceable chain from raw materials to finished product (branch-to-deployment traceability), and all logs are sent to an immutable archive that operators cannot delete (audit streaming). Each control exists not because it makes production faster, but because regulators require evidence that changes were authorized, reviewed, and traceable. Azure DevOps provides all these controls natively.

Audit logging in Azure DevOps captures every significant action: user authentication, permission changes, repository access, pipeline modifications, work item updates, and administrative operations. Azure DevOps Services provides audit streaming that continuously exports audit events to external systems: Azure Monitor Log Analytics, Splunk, or Azure Event Hubs (which can forward to S3, Datadog, or any SIEM). The critical property of streamed audit logs is immutability: once exported to the external system, Azure DevOps administrators cannot modify or delete the records, satisfying the separation of duties requirement. Compliance teams can query historical events to answer questions like 'who approved this production deployment', 'when was this branch policy modified', and 'which PATs were created in the last 30 days'. Audit log retention in Azure DevOps itself is 90 days; streaming ensures permanent retention in your SIEM.

Branch policies enforce code quality gates before any change reaches protected branches. For compliance, the minimum configuration on production branches (main, release/*) includes: minimum reviewer count (at least 2 for separation of duties), build validation (automated tests must pass), linked work items (traceability from requirement to code), comment resolution (all review feedback must be addressed), and merge strategy restriction (squash or rebase to maintain clean history). Branch policies cannot be bypassed by regular contributors: only users with explicit 'Bypass policies' permission can merge without meeting all requirements, and this permission should be restricted to repository administrators with audit logging of every bypass. The bypass itself appears in audit logs, creating accountability even for emergency changes.

Required reviewers automatically add specific approvers when changes touch sensitive code paths. You configure path-based reviewer policies: any change to /src/security/*, /infrastructure/production/*, or /pipeline-templates/* automatically requires approval from the Security team or Platform team before merge. This ensures that changes to authentication logic, production infrastructure, or shared pipeline templates always receive expert review regardless of which developer made the change. Required reviewers cannot approve their own changes (configurable), preventing the scenario where a developer modifies security-critical code and approves their own PR. Combined with minimum reviewer count, this creates multi-party authorization for sensitive changes.

Environment approval gates provide the deployment governance layer. Production environments are configured with manual approval checks requiring authorization from Release Managers before any pipeline deploys to production. Business hours checks prevent deployments during off-hours when incident response capacity is limited. Required template checks ensure all production pipelines use organization-approved templates that include mandatory security scanning, artifact signing, and compliance checks. The approval history creates an auditable record of who authorized each production deployment, when, and what version was deployed. This satisfies Change Advisory Board (CAB) requirements in ITIL frameworks and deployment authorization requirements in SOC2 CC8.1.

Organizational policies provide the top-level governance framework. Administrators configure: maximum PAT lifetime (30-90 days to limit credential exposure), external guest access restrictions (preventing unauthorized external collaboration), public project prohibition (ensuring all code remains private), alternate authentication restriction (disabling SSH keys or basic auth if not needed), and conditional access policies through Azure AD (requiring MFA, compliant devices, or specific network locations for access). These policies apply uniformly across all projects in the organization, preventing individual teams from creating security gaps.

The production gotcha is treating compliance controls as set-and-forget configuration rather than continuously monitored guardrails. Branch policies can be modified by project administrators, required reviewers can be removed from policies, and environment checks can be deleted. Without monitoring for changes to these controls, a compromised administrator account could disable protections without anyone noticing until the next audit. Best practice is alerting on audit events that modify security-relevant configurations: branch policy changes, permission group membership changes, environment check modifications, and organizational policy changes. Set up alerts that notify the security team immediately when these events occur, creating a detective control that complements the preventive controls.