When Danielle Koppel joined the Atlanta and Augusta chapters for our virtual Intro to GRC Engineering event, she opened with one of the clearest definitions of the discipline I have heard:
GRC Engineering is “using engineering practices to make GRC more measurable, repeatable, and automated.”
That definition is useful because it does not begin with a particular platform, programming language, or framework. It begins with the way we approach the work. We look for processes that can be measured, repeated, tested, and improved.
Danielle also gave us a helpful reminder that when a process repeatedly fails, the problem may not be the people involved. Sometimes the environment itself needs to change.
Building a better trash can
Drawing from her experience working with animals, Danielle shared the example of trash cans in national parks. For decades, visitors were asked to latch trash cans properly so bears could not get into them. The instructions were clear, but the bears kept finding their way inside.
Eventually, the solution was not another reminder for park visitors. The trash cans had to be redesigned.
It was a fun analogy, and no, the point was not that people who have not embraced GRC Engineering are animals. The point was that we work inside larger systems. When a process depends on every person remembering every step every time, repeated failure may be telling us something about the design.
Traditional GRC often asks people to remember to take a screenshot, upload evidence, check a configuration, update a spreadsheet, or notice that something has changed. More training and reminders can help, but they do not remove the weakness in the system.
GRC Engineering asks whether we can redesign that environment so the expected behavior is built into the way the organization operates.
Danielle put it this way:
“GRC Engineering is trying to do the same thing for compliance, not replace traditional GRC, but give the people already doing that work a better can. A screenshot proves someone looked once, on a Tuesday, months ago. That's not a failure of the person who took it, it's a limit of the tool they had. GRC Engineering is the redesigned can: a bucket that's encrypted because the Terraform module refuses to build it any other way, and evidence that exists because the pipeline produces it whether or not anyone remembers to ask.”
That example gets to the heart of the discipline. Instead of collecting a screenshot to show that a cloud storage bucket was encrypted at one moment, we can build encryption into the infrastructure code and prevent the bucket from being created without it. The control becomes part of the system, and the evidence can be produced automatically.
That is a much better can.
Not everything needs to be code
Danielle also made an important distinction: not all governance needs to be coded.
Code is valuable when the work is repetitive, rules can be clearly expressed, and the result can be reliably tested. It can reduce manual effort, produce more consistent evidence, and help identify changes much faster than an annual review.
But code does not eliminate the need for people who understand the business, the technology, and the risk.
Many of the risks organizations face today still require judgment. Someone has to interpret context, challenge assumptions, decide what is acceptable, and recognize when a technically compliant result still creates a problem. Governance involves people, accountability, priorities, tradeoffs, and decisions that cannot always be reduced to a pass-or-fail test.
The goal is not to automate people out of GRC. It is to stop wasting their time on work that a better-designed system could handle, so they can spend more time on the judgment that only people can provide.
We are building this while the field is changing
One thing I took away from the conversation is that GRC Engineering is still on the bleeding edge. We are not walking into a finished discipline with one accepted toolset and a single roadmap. We are helping define the practices, build the resources, test the ideas, and figure out where engineering makes GRC better.
That can feel intimidating, especially for practitioners who are still learning the technical side. It is also what makes this community valuable.
Danielle pointed attendees toward the GRC Engineering Club’s open-source GitHub resources. Those projects give practitioners something more useful than theory alone. We can inspect what others have built, try it ourselves, contribute improvements, and learn how engineering practices translate into real GRC work.
You do not need to become a software engineer before you can participate. Start by identifying one repetitive process, one fragile spreadsheet, or one piece of evidence that depends on someone remembering to take a screenshot. Ask what the system could do differently.
Technical careers need community too
Danielle closed by sharing another part of her work as the Executive Director of MilSpouse Coders, a nonprofit community that helps military spouses develop technical skills, stay connected, and build their career networks.
That mission fits naturally with the larger message of the evening. Better systems matter, but so do the communities that help people learn how to build them. Technical careers are difficult enough without having to navigate them alone, especially when military life can introduce frequent moves and other disruptions that traditional career paths were not designed to handle.
I appreciated Danielle giving the Atlanta and Augusta communities a practical introduction to GRC Engineering while also showing us the human side of the work. We need automation, repeatability, and better evidence. We also need judgment, access, encouragement, and people willing to teach what they know.
Thank you to Danielle for helping us rethink the systems around our work.
Now let’s go build some better trash cans.