How to Align GRC Controls With DevOps Workflows

TL;DR

Align GRC with DevOps by designing provable, repeatable controls around how engineers actually work, rather than forcing idealized procedures onto them. Calibration among auditors, engineers, and security teams can reduce needless work, improve audits, and support shared goals such as resilience, visibility, quality, rapid response, and systems that are secure enough for the business.

Transcript

Oh, thanks everybody. Good afternoon. Um, and thanks for coming. So, um, like John said, I'm Sue Allspaw Pomeroy, and I wanna talk today a little bit about how, uh, GRC and DevOps can start collaborating a little bit better than they have in the past. But first I wanna start with a story. A long, long time ago in a galaxy far, far away, I worked fo... Read More

Key Insights

• DevOps improves system safety by encouraging smaller, more frequent changes, while collaboration between development and operations helps teams build systems that are more reliable and resilient. These practices challenge compliance approaches that depend mainly on scheduled stakeholder meetings and managerial approval.
• Peer review and automated testing can provide meaningful change-control safeguards because peers may understand the code better than managers, while tests help verify that systems remain operational. The talk presents these mechanisms as alternatives worth considering when traditional interpretations require formal approval meetings.
• Compliance frameworks are broad collections of security knowledge and basic security measures that organizations can adapt to their own businesses. Their intended flexibility allows controls to reflect an organization's particular risk profile rather than imposing identical implementations on every company.
• Security frameworks can enable engineering work by supporting investments in visibility and tools for producing safer code. Smaller startups can also use framework requirements to justify funding for security programs that the business already wants or needs to establish.
• Poor framework interpretation creates unnecessary work when organizations implement complex controls or choose safeguards designed for a risk profile far above their own. Frameworks can also become rigid when teams treat their wording like law instead of considering their intended adaptability.
• Auditors, engineers, and security teams share goals that include resilience, visibility, quality, safety, and rapid response. Their conflict often comes from different methods, since auditors favor methodical and provable implementation while product and engineering organizations care strongly about speed and operational effectiveness.
• Calibration is the foundation of GRC and DevOps collaboration because the objective is not to force every organizational group to work identically. Teams must instead understand one another's context and develop controls that meet assurance needs while fitting actual engineering practices.
• Work as imagined differs from work as done because policies and process diagrams describe ideal procedures, while real operations involve new signals, changing information, and human judgment. Operators may deviate from a prescribed path while still pursuing stability, visibility, and other organizational goals.

Questions & Answers

Q: How can GRC and DevOps work together effectively?

GRC and DevOps can work together by calibrating their expectations around shared goals and actual operating conditions. Auditors should seek effective, repeatable, provable controls without assuming that traditional procedures are the only acceptable implementation. Engineers and security teams should explain how peer review, automated testing, monitoring, and operational judgment protect stability, visibility, code quality, and system safety.

Q: Why should traditional security controls change for DevOps?

Traditional controls should be reconsidered when they describe an idealized process that does not match how engineering work is actually performed. A requirement interpreted as a stakeholder meeting and manager approval may overlook protections such as peer review and automated testing. Changing the implementation does not mean abandoning control objectives. It means finding effective, repeatable, provable safeguards suited to real workflows.

Q: What do auditors need from DevOps security controls?

Auditors need security controls that are effective, repeatable, and capable of being proven. They generally favor methodical implementations and evidence showing that required practices operate consistently. Collaboration improves when engineering teams make their existing safeguards understandable and demonstrable, while auditors examine whether those safeguards achieve the intended objective instead of requiring another group to copy the auditor's preferred working method.

Q: What do engineers want from GRC programs?

Engineers want stable systems, the ability to respond quickly when systems become unstable, a common understanding of systems across teams and the organization, and visibility into why systems behave as they do. A useful GRC program supports these goals through appropriate tooling and controls, rather than adding complex procedures or paperwork that do not match the organization's actual risk profile.

Q: What do security teams need from DevOps monitoring?

Security teams need systems that are secure enough, code tested against the stated security concerns, visibility into unusual activity, and rules followed by both people and systems. Monitoring should account for operational context. For example, an action performed at an unusual hour should trigger a page only when it is genuinely abnormal, not when that behavior is routine.

Q: How should a company adapt a compliance framework?

A company should adapt a compliance framework to its business and risk profile because frameworks are intended to cover a broad range of security knowledge and basic measures. The implementation should provide effective protection without introducing complexity intended for a much higher level of risk. Thoughtful adaptation can also support funding, visibility, safer coding tools, and a stronger security program.

Q: What is the difference between work as imagined and work as done?

Work as imagined is the ideal process described while designing frameworks, controls, policies, wiki documentation, and process diagrams. Work as done is the messier reality in which operators receive new information, interpret signals, and sometimes deviate from a documented procedure while still trying to meet operational goals. Comparing the two reveals where controls and actual practice require calibration.

Q: How can GRC make audits smoother for DevOps teams?

GRC can make audits smoother by communicating frequently with engineers and security teams, understanding how safeguards operate in practice, and translating those practices into repeatable, provable controls. This reduces disconnected work and helps auditors evaluate real protections. It can also make engineers happier because they can demonstrate safety through workflows that support stable systems, rapid response, visibility, and quality.

Summary & Key Takeaways

• GRC and DevOps can collaborate effectively when both groups recognize their shared goals while respecting different working methods. Auditors need effective, repeatable, provable controls. Engineers need stable systems, rapid response capabilities, shared understanding, and visibility. Security teams need well-tested code, useful monitoring, and rules that distinguish normal behavior from unusual activity.

• Compliance frameworks cover broad security knowledge and basic protective measures, but they are intended to be adapted to a business and its risk profile. Used thoughtfully, they can secure funding and provide engineers with visibility and safer development tools. Misinterpretation can instead produce excessive controls, rigid processes, needless work, and extensive paperwork.

• Effective collaboration requires comparing work as imagined with work as done. Written policies, process diagrams, and ideal workflows rarely capture every signal or decision operators encounter. People may deviate from prescribed procedures to preserve stability or meet operational goals. GRC must understand this context and calibrate controls with actual engineering practice.