The next shift-left: Compliance

Shift Left

While dreaded the “shift-left” approach for test engineering has provided an important lesson for future automation imitatives. With tests being automated and running continuously, they help to provide faster time to market. With tests being automated, we have a more precise acceptance criteria coverage and often a broader test coverage.

Shift-left has enabled many teams to deliver fast and with sustainable quality following DevOps practices. I trust the research from DORA, that coded testing automation should be established by the people developing the features. As an industry we know this is a successful approach.

The original DevOps hand book framed the challenge of adapting and delivering reliably like this: “the chronic conflict of pursuing both: responding to the rapidly changing competitive landscape for features and platforms while maintaining business as usual”.

Both Adapting to Change and Delivering Reliably

One flaw with shift-left is a bias to “automate everything”. There is a quality mindset to it though, where the people developing things can come short, and need a testing professional. Beyond coded testing, there are plenty of things for a testing mindset to explore collaboration, coaching and framework building.

We can describe shift-left as an early encoding and continuous evaluation of the (functional) requirements. Looking at it from an evolutionary perspective, the evaluation of the requirements moves from a hand-driven approach, that is at best built for purpose, to a mode where it’s integrated and repeatable. See more on #WardleyMapping

Shifting the Compliance Controls

With the increase in IT security regulations, Data Governance laws many companies face the challenge, that they have to be consistently in control of their IT and data. The companies and development teams are facing a new set of requirements- compliance controls.

Testing Is The New Black

Is this the first time you have a compliance testing challenge? It’s not my first time.

Leading Testing ActivitiesJesper Ottosen

The is a clear and present danger to organizations that do not take this seriously. It’s not a matter of if your data or IT is being breached or is being scanned for vulnerabilities. It’s already happening. How prone are your systems when natural disaster and adverse weather brings down your operations or hinder your team in working. While annoying the regulatory controls makes business sense, in protecting both the organization and the society.

For years though, the work of the GRC staff has been supported by spreadsheets after spreadsheets listing all the controls, listing the evaluation and perhaps listing some evidence of the fact. At that point in time. Like old test case execution logs, that this looked to be working at that point in time.

GRC Engineering

All the controls needs to be valid at all times, not only at audit time and thus needs to be more repeatable and less established by hand. The tools and techniques are already in place for this. Commercial GRC tools helps to move the exercise from spreadsheets to a tool, but what is really needed is the experience from shift left and DevOps practices. Over the last few months the term “GRC Engineering” has emerged exactly for the early encoding and continuous evaluation of the (compliance) requirements.

🤔 Why isn't GRC Engineering everywhere yet? | Ayoub Fandi posted on the topic | LinkedIn

🤔 Why isn’t GRC Engineering everywhere yet? If things aren’t moving fast, it’s not because legacy GRC pros are dumb or want to hold on to spreadsheets for dear life. It’s because organisational change management is actually a thing. We are quick to blame individual practitioners when the systems in which they operate create the inertia we are criticising. Everyone underestimates inertia. DevOps took years to become ubiquitous, and many companies still aren’t leveraging proper DevSecOps workflows. The Phoenix Project came out in 2013, 12 years ago. When existing processes work “well enough,” the business case for transformation becomes exponentially harder. I would argue that for GRC Engineering, the hurdles are way bigger: 🚀 Startup paradox: Natural early adopters that power most of the technology innovations get GRC engineering out-of-the-box from automation platforms. They didn’t hire dedicated GRC before Series A, now with vendor solutions handling the plumbing, it’s becoming Series B+ before they need internal capability. 🏗️ Legacy infrastructure reality: You don’t inherit greenfield environments. Every enterprise implementation means working with legacy systems, existing workflows, and embedded processes that weren’t designed for modern automation approaches. 🎓 Skills gap magnitude: Unlike DevOps (technical to technical), GRC Engineering bridges compliance and engineering domains. Most GRC professionals came from accounting, law, or business - making reskilling exponentially more challenging. The real barriers are systematic: organisational maturity, technical debt, and the gap between “automate evidence collection” and “continuous control monitoring.” Bad frameworks, old-school auditors and love for VLOOKUPs isn’t what is holding the industry down. More on the systematic barriers and culture transformation frameworks in upcoming posts. #GRCEngineering #SystemsThinking | 23 comments on LinkedIn

LinkedInAyoub Fandi

Imagine owning the first Airbnb in a now-famous tourist spot before anyone knew what Airbnb even was. | AJ Yawn | 24 comments

Imagine owning the first Airbnb in a now-famous tourist spot before anyone knew what Airbnb even was. That’s what it feels like to be early in GRC Engineering right now. We’re at the start of something big. In the same way cloud security exploded, we’re now watching GRC evolve in real time. We’re going from checklists and policies to engineering and automation. And just like early cloud security pros became go-to experts, early GRC Engineers will become the most valuable people in the room. This is an important and overdue shift. The roles built on templates, spreadsheets, and recycled control sets are phasing out. But that doesn’t mean you have to be left behind. It means now is time to build something new. If you’re willing to learn Python, explore AWS, and ask better questions, If you’re curious, resourceful, and ready to grow, You can define this next era. GRC Engineering is way more than just a new job title. It’s a massive opportunity. And you’re not too late to be early. #GRC #GRCEngineering | 24 comments on LinkedIn

LinkedInAJ Yawn

There are two different worlds simultaneously existing right now in #GRC | Lloyd Evans 🌩 | 31 comments

There are two different worlds simultaneously existing right now in #GRC World 1️⃣ Example: Auditors/Assessors (especially in Federal environments) pushing back on automated control validations while defending point-in-time manual checks. World 2️⃣ Example: A security engineer mapping their product to relevant controls through an LLM and the output being good 🔥 I saw both these examples this week. World 1 is rapidly dying. World 2 is sprinting forward. This is a call to action to learn the skills that enable success in World 2. 🏄 We can’t control the shifts, but we can learn how to better ride the wave. #GRCEngineering | 31 comments on LinkedIn

LinkedInLloyd Evans 🌩

As with shift left and DevOps, there will be a cultural backlash, as auditors will be seeing new forms of evidence - screenshots, systems values and perhaps even video feeds. This is the exact same backlash I faced about five years ago with test automation evidence in new formats. The life science schooled QA/QC auditors hadn’t hard time grasping the new way of collecting compliance evidence. There will be a similar pushback from people having a vested interest in keeping status quo in spreadsheets and manual processes.

To me this trend is as inevitable as with all IT knowledge work. To scale and solve the core conflict we need to shift compliance left and encode the controls. This time around we have the collective knowledge from DevOps practices, research and test engineering. Eventually I would prefer integrating governance into DevSecOps - Development+Security+Operations, but more about that in another post.