3 ways to meet compliance needs without slowing down agility

Compliance doesn't have to mean friction

Compliance programs that grind software delivery to a halt are a choice, not a requirement. By focusing on a handful of repeatable, traceable controls that already fit within modern development workflows—code review, segmentation of duties, and clear terminology—engineering teams can stay in flow while still meeting regulatory expectations.

Fundamentals first: review and access control

The most straightforward compliance wins are usually the ones already embedded in good engineering practice. Two controls deserve particular attention because they handle both quality and auditability.

Code review is a critical step for producing clean code, and it also serves as a foundational audit control. A repeatable, traceable review process catches delivery risks early and creates a lasting record for future compliance reviews. With pull requests already a standard part of the developer workflow, reviews don’t require a separate process or tool. Auditors and compliance testers can later examine pull requests along with central, immutable audit logs without disrupting anyone.

Separation of duties is another area where a modern, function-based approach removes friction. Older interpretations often define this control by limiting what a single person can do manually, which conflicts with cloud native delivery. Industry guidance, such as the PCI-DSS requirements, shifts the focus to separating development/test functions from production functions rather than restricting individuals. A developer may hold an elevated account in a development environment and a restricted one in production.

This aligns with a build/release/run methodology, where separation across those stages is enforced by unique IDs and rollback capability, not by limiting human action. When functions and accounts are separated with traceability to unique IDs, delivery automation does not require manual oversight of a person who might exceed control.

Enabling this separation requires an identity and access management strategy. GitHub Enterprise provides several routes:

• SAML single sign-on verifies users against an existing identity provider, adding an authentication check while preserving individual GitHub accounts.
• Team synchronization with identity provider groups means changes in group membership automatically update GitHub team membership and the access associated with it.
• Enterprise Managed Users (EMUs) provide a GitHub Enterprise flavor where login is only possible through centrally managed identity provider accounts, removing the personal-account-plus-SSO pattern.

Automation for dependency and approval controls

Managing supply chain risks and release approvals are two areas where immature controls slow things down. Both can be automated and audited without much overhead.

Dependency management is increasingly central to compliance programs as open source reliance grows. Dependabot alerts developers as soon as a known-vulnerable dependency surfaces in a repository. Developers or security teams can then trigger pull requests to remediate, generating auditable artifacts. Every alert is an immutable record for review.

Approvals are required at various points—from testing results to production readiness. The danger is letting approval gates skip past development and surface too late. Peer review, per DORA findings, is a more effective way to streamline change approval than heavyweight bureaucratic sign-offs. When approvals are actually needed beyond code review, manual approval for pull requests works well in the build/test stage. For deployment, GitHub Actions environments can describe targets like staging or production and require reviewers to approve before a deployment job runs.

The tradeoff here is visible: too many required approvals or manual touchpoints will throttle delivery. Automate as many checks as possible, and reserve manual sign-off only for steps where it genuinely adds value.

A shared vocabulary for developers and auditors

A recurring obstacle in compliance work is terminology. Developers and cloud native teams routinely use specialized language that makes little sense to compliance testers and auditors, which creates friction for everyone involved.

The DevOps Audit Defense Toolkit, created by Gene Kim and others, helps educate practitioners on audit and risk concepts. A starting point that is actionable today is to map GitHub-specific control objectives to the language of compliance: an agreed-upon cheat-sheet of terms that bridges engineering and audit perspectives. The table below offers such a starting point.

One finding from a Forrester economic impact report highlights what happens when developers and auditors share a frame of reference: standardized documentation structures made it easier for auditors to locate the materials they needed, helping organizations speed up preparation for compliance and security audits.

The path forward

Emerging capabilities may soon improve the efficiency of these controls. You could lean on generative AI to spot nuanced issues inside a unit test or a requirements log that a human might miss—though on this point, practitioners should temper expectations as those tools mature. There is also active research into quantifying the trust in results from AI and deep learning models. As this technology matures, it can complement the audit process rather than displace the foundational work.

Meeting compliance needs doesn’t require reworking your culture or waiting for a new tooling wave. Firms that make basic controls excellent, keep a clear shared vocabulary, and use modern access and deployment capabilities will find compliance no longer blocks agility.

Compliance as a team sport: the three lines of defense

Risk management and governance frameworks often feel abstract to engineering teams. The three lines of defense model is one way to make those responsibilities concrete, clarifying which teams own which parts of risk mitigation.

In practice, the three lines map directly onto your organization:

• First line: engineering teams. The developers and engineering leads shipping software are the first line, since they work closest to the code and its risks. They need enough security skill to identify risk within their own solutions. The key is ensuring that capability exists at the team level, not just in a central security group.
• Second line: organizational oversight. Frameworks, policies, and tooling provide risk management at scale. This layer measures how well the first line is implementing mitigation techniques, defines what risk means across the organization, and keeps that definition consistent.
• Third line: internal audit. This is the independent check on whether risk management and governance are effective. Like the red team complementing the blue team, internal audit completes the picture by working with senior management and external regulators to validate the controls that are in place.

An analogy may help teams internalize this. A hockey team that only scores goals but cannot defend rarely wins. One that only defends but cannot score fails too.

• Forwards are the first line. They create solutions that provide business value while also being secure. They may be pulled into defense, just as engineering teams are responsible for the security posture of what they ship.
• Defenders are the second line. Their role is preventing goals, but they partner with the forwards on whatever is the current priority. That mirrors the compliance team collaborating with engineering on risk oversight rather than simply policing.
• Goaltender is internal audit. Independent of the forwards and defenders, they bring different responsibilities, tools, and perspective to the game.

The same logic holds for business outcomes. A solution that satisfies customers but is insecure will fail. A solution that is secure but provides no user value will fail just the same. Success is a balance of value creation and risk management, and it takes all three lines working together to find it.

For developers, this framing clarifies that they are "forwards"—scoring goals by shipping software—while also supporting the defense. They do not need to take on internal audit responsibilities or become governance experts. But their security work is a necessary support for the wider team, and recognizing that place in the model makes the ask concrete.

Bringing it together

GitHub's workflow controls—branch protection rules, pull requests, CODEOWNERS, and environment approvals—are practical starting points for weaving compliance into development. But tooling alone solves only part of the problem.

The missing piece is a shared language between compliance and DevOps practitioners. Without it, the implemented controls are hard to demonstrate or evaluate. With it, everyone sees that compliance is a distributed responsibility, and engineering teams hold a documented position in the three lines of defense.