AWS re:Invent 2025 - A leader's guide to achieving compliance through software excellence (SNR304)

🦄 Making great presentations more accessible.
This project aims to enhances multilingual accessibility and discoverability while maintaining the integrity of original content. Detailed transcriptions and keyframes preserve the nuances and technical insights that make each session compelling.

Overview

📖 AWS re:Invent 2025 - A leader's guide to achieving compliance through software excellence (SNR304)

In this video, Tom Godden (AWS Executive in Residence, former CIO at Foundation Medicine) and Ian Sutcliffe (Principal Tech Strategist) present a framework for achieving "natural compliance" through software engineering excellence rather than documentation theater. They argue that traditional compliance approaches cost financial services $30 million annually per company and healthcare $1 trillion yearly, with 98% of companies reporting rising costs. Their solution involves four pillars: culture (shifting from compliance-checking to quality focus through weekly demos and automation), organization (embedding compliance experts in product teams, eliminating handoffs), mechanisms (using existing tools like JIRA and CI/CD pipelines to auto-generate compliance evidence), and execution (90-day transformation sprints starting with small wins). They emphasize that modern regulators like the FDA now encourage automated testing over documentation, and that requirements should be managed in tools rather than Word documents. The framework promotes test-driven development, infrastructure as code, immutable pipelines, and continuous validation on every commit rather than quarterly cycles.

; This article is entirely auto-generated while preserving the original presentation content as much as possible. Please note that there may be typos or inaccuracies.

Main Part

Introduction: Rethinking the Relationship Between Compliance and Innovation

Hello everyone. Thank you so much for joining us here today. This is "A Leader's Guide to Achieving Compliance through Software Excellence." This is a super exciting topic. My name is Tom Godden. I am an Executive in Residence with AWS. Our Executive in Residence team is made up of 15 former CIOs and CTOs from large multinational companies. I was the Chief Information Officer at Foundation Medicine. For those of you who don't know, Foundation Medicine is the world's largest genomics company based in Cambridge, Massachusetts. A lot of what we did and focused on was doing exactly these types of things.

I'm very lucky here today to be joined by my colleague Ian. Why don't you introduce yourself? I'm Ian Sutcliffe. I am a Principal Tech Strategist in our Healthcare and Life Sciences industry vertical. My background is primarily in life sciences, so medical device and pharmaceutical. I've held anything with "architect" in the title.

Wonderful. Well, let's go ahead and get started. This is a topic that I'm sure you're all excited about because, maybe if you're like me, compliance can feel overwhelming. Maybe you're drowning in documentation, or maybe unfortunately you're just watching your competitors move faster. We've accepted as an industry that innovation and compliance are opposing forces, that we cannot have simultaneously. But what if that isn't true? What if we could use them to actually reinforce one another to go faster, to innovate more, and to have better compliant and higher quality software?

We're going to talk with you about an approach that Ian and I have individually done and we've worked with other organizations on—how software excellence makes compliance more of a natural outcome of your activity. Before we dive into solutions, we need to acknowledge an uncomfortable reality. The compliance approach that we've all inherited wasn't designed for modern software, but it is being ruthlessly applied to modern software.

Let's face some uncomfortable truths about what that's costing us and the implications. I want to start with a question that might make you uncomfortable. What if our compliance teams are actually solving the wrong problem? What if those hundreds of hours that we're spending trying to document compliance are just chasing shadows? What if compliance could actually emerge solely from good engineering?

Let me introduce you to natural compliance. It's how we learn to stop fighting the forces within these organizations. When you build software with excellence, compliance becomes automatic, like a healthy tree bearing fruit—no force, no additional additives. This isn't about lowering standards, and I want to be clear on this. I've talked to lots of executives in highly regulated spaces. No one is talking about being reckless. No one is talking about lowering quality. In fact, I want to raise quality as we go through and how we approach this. It's about how we achieve that in a different way.

Traditional Compliance vs. Natural Compliance: The Cost of Documentation Theater

Let me dive into the details on how these approaches differ. They aren't just different processes in how we approach this. They're fundamentally different worlds in how we do this. The traditional way of achieving compliance is you build it, you create it, and then you scramble at the end. Maybe you're better than I was with my teams, but you bolt compliance on at the end. It's kind of like our souped-up car there on the left. This creates what I call documentation theater—it looks good, you're required to have it, it's impressive. Look at this stack of documents I created. I won't go so far as to say it protects little, but it doesn't actually drive the results that we want to have.

The natural compliance way builds excellence in. Compliance is engineered into the process and the workflow of doing software development. Here's what's transformed our thinking. These aren't competing priorities. Speed, quality, and compliance—the breakthrough that changes everything is when we pursue them all together.

Automated testing helps quality and provides that compliance evidence. Continuous monitoring improves security and satisfies those audit requirements. But let's be honest about what traditional compliance is costing us. In financial services, $30 million annually per company.

Compliance is costing us significantly. In financial services, the estimate is $30 million annually per company. In healthcare, it's a trillion dollars yearly in administrative burden across the entire ecosystem. We're trading speed and innovation in this new modern AI world for theater, not getting into actual production and getting actual value. Unfortunately, the news is that it's getting worse. Ninety-eight percent of companies report that their cost of compliance is going up. Sixty-one billion is just for the United States for financial crime compliance. Forty-two percent is labor costs—people doing the manual work that systems could be doing. This trajectory is simply not sustainable, not only economically but from an innovation standpoint.

The Fundamental Mismatch: Why Current Compliance Approaches Fail Modern Software

In this new world that we live in, here's a number that should drive every compliance decision: for every dollar you don't invest, you'll pay $2.71 in penalties. This isn't theoretical; it's from research across 53 companies. It poses the question: why can we not afford to transform and make these changes? Here's why we have this problem. It's a fundamental mismatch in thinking. Compliance wants a snapshot—what did your software look like the day you deployed it so they can stamp it and file it away forever into a filing cabinet that will only get accessed when your auditor shows up and says, prove to me that you did that. That's theater.

But the reality is that software is continuous. It's not a photograph; it's a movie. It deploys and should deploy daily, be updated on a regular basis. By the time we validate and document the software, it's already moved on—at least it should have already moved on. This isn't wishful thinking. In fact, regulators worldwide are beginning to endorse this kind of automation. I remember when I sat down with my auditors from the FDA. I'm sure many of you have experienced the same. I talked to them and said, you realize you're having me spend more time proving to you that I have good quality than actually investing in good quality. The good news is we didn't have a quality problem at Foundation Medicine, but it was so far out of balance. We're seeing them find this approach. The FDA is moving towards this least burdensome approach. They prefer finely-tuned testing over documentation.

The regulatory world is actually screaming at us and telling us to modernize. We in this industry just need to listen. For the first time ever, those regulators are helping us go faster. The FDA says do more automated testing, not write more documents. Cloud platforms deliver enterprise-grade compliance capabilities built into these solutions. Digital native companies are shipping daily. In some cases, they're still validating quarterly, but the hidden costs go just beyond operational delays and rework—three to six month validation cycles. How many of those did I have? Talented engineers want to build innovative solutions. They don't want to write word documents. Meanwhile, new companies use modern approaches to ship continuously.

The good news is that Ian and I are going to take you through how you can adopt some of these practices. Here's the pivot that changes everything: stop fighting compliance with more documentation and procedures. Instead, start achieving it through engineering excellence that works naturally. Compliance becomes the result, not the enemy of innovation. You might be wondering, okay, sounds good—what's there to object to so far? But how do I do this? After working with dozens of companies, we found a pattern that has worked: four pillars that must align. Fortunately, if you miss one, everything's going to fail together.

First is culture. We've heard it so many times in any transformation. Culture is so critical and important, but it's also important how we think and organize our teams to succeed. We need the appropriate mechanisms, the processes, the procedures, and how we operate. And then finally, you've got to deliver—it's time to execute.

And let me walk you through each one and how they build upon each other. You might think this works well in the pharmaceutical industry with the FDA, but every regulatory industry faces this same exact challenge. Healthcare drowns in documentation, financial services struggles with validation, and the root cause is identical. So Ian and I are now going to take you through this solution foundation. I'm going to turn it over to Ian to break down how we look at these cultural, organizational, and mechanical aspects to help you understand how we can achieve natural compliance.

Framework Foundations: Attributes of Progressive Organizations

Thank you Tom. Alright, so as Tom said, we have developed this framework. AWS likes frameworks—you may have heard of the Cloud Adoption Framework or the Well Architected Framework. We like these frameworks. Let's cover some of the foundations first. This will give you an idea of why we're developing this framework and some of the benefits you can gain from it. Again, this is not theory; this is work we've done with numerous customers, and we've condensed that experience into these assets. There's no accelerator for experience, but we've come up with these assets. Let's look at some of the attributes of what we consider a more progressive organization.

First, separation of concerns. One of the main problems we see is the combination of product quality teams and IT quality teams. We need to separate them and pull them apart. We need to allow product quality teams to define the control objectives and requirements, but then defer to IT quality teams to actually decide how to implement those controls. The control framework is the middle ground where the two teams collaborate. They get together, put their heads together, and define those control objectives, but they leave the actual implementation to the IT experts. We want to avoid situations where quality is saying you need to demonstrate your product quality controls by producing a particular document using this template. We want to shift away from that old way of working.

Traditional quality management stemmed out of the manufacturing world, where you have a production line and product quality is influenced by the consistency of the process. You log the processes to ensure a certain level of quality for that product. But in IT, every product is different. Every IT system has different architectures and different technologies. We need to adopt a quality management system with flexibility of process. Stop locking it into a single SOP-mandated way of delivery. Automate, automate, automate. If you're doing anything twice, automate it. If there's IT tooling that can do the job, use it. We're shifting away from manual processes and document-centric processes to leverage the tooling that any self-respecting IT engineering team is already using today.

What we want to provide these dev teams is what I'm calling freedom in a box. You provide them an environment in which they can operate quickly and efficiently, deliver business value, and focus on delivering that business value without having to worry about compliance all the time. We want to take that lift off their shoulders. Few more attributes: shift left. In a lot of traditional IT organizations, compliance work happens late in the development cycle, during the testing phase. We want to shift as much of that up and to the left as possible. You'll see from regulatory agencies like the FDA that quality by design is a big thing—a culture of quality. We want to instill that into the IT processes so that it's considered upfront.

System documentation is another key attribute. Too often I see IT teams creating system documentation as part of their SDLC, but there are still SOPs around these things. If you want to control a manual process, you have an SOP, fine. But as soon as you automate that process, all of that information is transferred into the system documentation, workflows, and design documentation. In those situations, you should be retiring the SOP. Yet we still see the two being maintained in parallel. Finally, capture artifacts.

As an engineering team, we want to be generating these compliance artifacts naturally as part of our day-to-day work. We don't want to be doing extra activity just for ticking compliance boxes. The immutable pipeline and immutable production are key attributes we're looking for. We want to ensure that all change goes through a pipeline where we can demonstrate control in an automated way. We are generating data, which serves as our records and our proof of compliance.

We want an immutable production environment where we prevent people from directly accessing production accounts through the command line interface or the console. As soon as you allow that, you run the risk of drift and things getting out of sync with what you've already documented in your system documentation. That's why we put this framework together.

The benefits are significant. Speed increases by eliminating handoffs between teams. Quality improves by finding issues early rather than fixing them late. Risk drops because we're enforcing compliance. We've shifted left and built the controls into our tooling and our processes. Efficiency increases because we're removing waste from our processes. And talent stays or is attracted to high performing engineering teams because they get to focus on the cool stuff rather than worrying about compliance.

There's a cost benefit principle we've known in the IT industry for a long time. The earlier you can identify a defect or an issue and the quicker you can fix it, the cheaper it is. If you fix a problem in the requirements and design phase, you incur a cost of a dollar. It's an order of magnitude greater if you're fixing things in production. The typical compliance phase, however, is at the tail end of this cycle. It's maybe not production, but certainly in the testing and deployment phase, that's typically where there's a lot of compliance activity. So it's already a higher cost. We want to shift that left.

Many of you here already have a gold mine of information. Pretty much any engineering team these days is using tooling like JIRA for requirements management, Confluence for documentation. You've got CI/CD pipelines and automated testing happening. These are all generating data or IT records. This is your compliance documentation, your compliance evidence. It makes no sense to extract your requirements from JIRA just to create a document. Just manage them in the tooling. Leverage the tooling. Stop creating Word documents when you can manage everything in this tooling. The fundamental equation of trust is changing.

We used to trust people and processes. Now we're saying we'll trust the tooling, the automation, and that immutable evidence that this tooling is generating. The automated controls, the immutable evidence, and now that equals trust. We're trying to change the mindset.

Pillar One: Building a Culture of Quality Through Transformation Teams

As Tom mentioned, one of the biggest things that has to change first is culture. Culture is what will derail any transformation effort. You may have the best tooling in the world and great architecture, but 70% of transformation efforts fail because of culture. That's what the first pillar is about. That's what we want to tackle first because it's the hardest part. This was confirmed by McKinsey, who did research again confirming that 70% of transformations fail. The reason is not technology.

It's culture and resistance. You can buy the best tooling, but with the wrong culture, you're going to have an expensive failure. As I always like to say, culture eats strategy for breakfast. You can have the best plan in the world, but without addressing culture first, you're going to fail.

We're trying to shift from a culture of compliance to a culture of quality. I always contend that if you adopt a culture of quality, compliance is a natural byproduct. We want to shift from this idea of checking "Did we follow the SOP?" to "Does the system actually work?" This becomes a new mantra when you get back to the office on Monday.

If you've recovered from replay, start to reinforce this with your teams and start to change their thinking. First, we need to create a transformation army, but it's a tiger team—a small team. We want to find those champions with the willingness and eagerness to go out and help with this transformation. Roughly 20% love automation. If they do something twice, they will automate it. If 10% of quality professionals have an interest in growing beyond what their role is currently defined as, these are the people you want to get first.

Work with them. Those that are keen—avoid the skeptics for now. We'll deal with them in a future phase. The mission of this team is to automate the compliance checks, and we want a continuous flow of these compliance checks coming out of this team. We want to show working systems, not slides. This is a practice that has transformed dozens of cultures. It's proven to work. We've worked with a lot of customers, and it's around demos. Weekly 30-minute demos show something working. A working system will build trust faster than slides ever will.

Start with your team in the first few weeks and try to build some of these automations. After a few more weeks, show it to your management. Around week 12, actually invite auditors in and show them what you're doing. Get them on board. No framework would be complete without metrics and measures. What gets measured gets done, but what gets celebrated gets repeated. You can track the leading indicators—automation coverage and demo attendance—but celebrate them. Celebrate those monthly wins, promote these champions, and have it improve their career. Encourage them to start adding to this.

The goal is to make compliance so automated that nobody really thinks about it anymore. That may sound contrary to this whole career progression, so you need to celebrate these wins and these automations. Link their careers to these. We've covered culture and hopefully we've nailed that. We've got people and the mindset is changing. We then need to match the organization to it. This demo culture creates something powerful—people wanting to automate. When the teams see the automation working, they naturally start thinking about automation first rather than the old manual processes. That mindset shift is starting to happen, and we need to start breaking down these silos, avoid silos from fighting each other and turf wars, and try to bring them together.

Pillar Two: Organizational Alignment and Embedding Compliance Experts

You can't reorganize people that don't want to change, which is why culture must come first. But once teams start to see this automation working and that mindset shift starts to happen, you start to see them no longer trying to defend their territory but start to ask how can we work together? They're seeing the value. This is when you can start to break those silos by embedding compliance experts in your teams. In several of our frameworks, we always like to promote this concept of a product-based operating model where you build the team around a product and they have all the resources that they need. There are no handoffs between organizations. The same concept applies here, but now we're bringing compliance experts into the team.

They're no longer a review step after you've done some work. They're actively embedded in the team, providing input. They have a vested interest in this product working and being compliant by design from day one. One of the things you always see is waste or lack of efficiency. Traditional organizational structures often slow things down, kill speed, kill innovation, and create waste because every handoff introduces delay. Two to four weeks, information gets lost. It's like playing Chinese whispers. It's not working. Every handoff degrades information.

It introduces waste. When your compliance team sits in one building and your dev teams are in another, you are unable to answer the question of how can we go fast and meet these requirements? The questions drop between the cracks between organizations. We need to rethink how we organize these things. What does transformation look like on the ground?

Quality professionals get brought into the product teams, so there is no handoff anymore. The compliance engineers sit in the standups with your dev teams. As part of their career progression, they also start to write code, starting small. They look at automation and try to automate their own checks. They really start to get into this automation mentality. The old review gates start to disappear because it is all built in.

World transformation starts to happen. The skills start to shift as they upskill, the decision rights happen within the product team, and you start to see a positive impact on these success metrics. No framework is complete without governance models. Here we want to try and split the what from the how. We want quality teams to define the standards and the requirements or set those control objectives, yet defer to IT teams that really understand automation and the technical implementation to figure out the best way of implementing those controls. The key is both sides working together in real time, not sequentially handing over but together, and creating this cycle much smoother than the old school handoff approach.

I mentioned earlier things like the cloud adoption framework and product-based operating models. A foundational piece is the platform team. For example, to create your landing zone, you have a cloud center of excellence sitting around that. The platform team is an enabler of multiple dev teams. They start to take some of that compliance heavy lifting off the shoulders of dev teams and build capabilities into the underlying platform. This could be account vending or baselining your accounts. You have that freedom within the box because you are giving them an account that already has all the guardrails around it. You can create building blocks, which are pre-approved infrastructure as code like CloudFormation templates, made available to them through a service catalog. These are things they can start to use, shifting towards self-service. The platform team becomes a great enabler of this.

There is going to be some upskilling. I mentioned those compliance engineers. We need to establish some training paths for them, linked to their own career progression. Those compliance engineers that used to just handle documentation all of the time start to shift towards automation experts. Teach them basic coding, teach them the automation tooling, how to use testing tools. All of these things make them aware of how CI/CD pipelines really help compliance. Get them embedded in the product team but upskill them so that they understand what we are talking about.

Here is an idea of your first week. When you get back to the office on Monday, fully recovered from the replay, pick some kind of control that you want to implement. Maybe you want to turn on Git signing so that you are starting to generate evidence whenever there is a commit in your Git repo. Create that first compliance test. Start to collect that evidence on Wednesday with basic dashboarding. Now that you have the data and the evidence, create a dashboard to show it. Demo to the auditor. Week one, you already have one control potentially automated in collaboration with your IT teams. This is going to start that flywheel of producing more and more of these controls.

We have got culture, done tick, got the organization hopefully aligned, and something great happens then. The technical work and generating this evidence starts to become natural. These are not theoretical concepts; they are patterns that are working in production today with many of our customers. Let us look at more into these mechanisms.

Pillar Three: Mechanisms for Automated Compliance and Evidence Generation

We'll do a compare and contrast. When compliance is automated, it almost becomes invisible. It's just a natural byproduct of your day-to-day work. It's happening naturally as part of your dev team's day-to-day work through proper automation. However, when you do manual testing, your validation cycles never actually catch up to your rate of delivery. By the time you finish validating, your systems have already changed. Tom mentioned this. It's the same even if you buy off-the-shelf software. You install it, start your validation cycle, report a bug to the vendor, they have to fix it and patch it, then you have to restart your cycle again. It's just this never-ending pain of validation, never keeping up with the pace of change. We need to change that.

When you get to the audit, every audit becomes an archeological investigation into piles of documentation that are already out of date. It's painful. We really need to encourage test-driven development, test automation, and anything to make testing faster so that every commit and every release gets validated every single time. Requirements in code may be a step too far for some, but the message is that requirements don't need to be in a Word document or in any user requirement specification in a set template format. You could store your requirements in JIRA and manage them there. Demonstrate control over your requirements management using the tooling. If you're having to extract your requirements to create a document, something is wrong with your process. Talk with your engineers and quality engineers.

Every time your code changes, you're going to have to update the requirements. You could actually use them. You probably see it in the hallways. Anything to do with JIRA and spec-driven development is a great new tool. You should really look into it where you're capturing the requirements in a specification. JIRA is helping you develop those. It's requirements embedded in the code almost. What's interesting is that the regulations have been around forever. They haven't changed in many years, but what they're actually asking for used to require specialized systems to capture audit trails and have e-signatures. These capabilities are now built into your regular IT tooling. Yet we're still using old-school processes and document-centric processes instead of using the capabilities in the tooling we already have. We need to shift.

You are already generating all the evidence. As we mentioned, the tool chain from requirements management linked to your test management tools, CI/CD pipelines that tell you what was deployed and when, defect management tools, and automated testing—you have that plethora of evidence already in your tooling. We need to bring it together. There isn't an integrated tool set that brings everything across your entire SDLC into one place. Let's start to draw that data together into a compliance data lake or data virtualization. Pull it together so you can automatically generate things like traceability matrices. It's very easy once you have the data.

Turn every system into a compliance generator. Start by inventorying what you have today. Odds are you have requirements management. You're probably using CI/CD pipelines. You're performing security scans. Start to inventory what you have and start to pull that together into one place with the goal of auto-generating reports if needed or answering questions that are going to come from your inspectors. Make your pipeline your validator. Think about the current validation cycle. You're probably doing it quarterly. It's very stressful. We are striving for validation on every commit. So you commit something with a pull request, it triggers the CI/CD pipeline. The pipeline has all the compliance checks and does automated testing. You are validating after every release. We don't want to be scrambling every quarter to do this. It becomes a natural part of your normal way of working.

Apply this to infrastructure as well. One of the big things with cloud was the introduction of infrastructure as code.

We all do it with code, so do it the same with infrastructure. Now we have a CloudFormation template, we do a pull request, it gets reviewed and approved, triggers a pipeline, and gets deployed through CloudFormation or Terraform—your choice. We have the same mechanism now of controlling infrastructure as we did with code, and it's generating evidence. We had the old IQ, OQ, PQ and regulated systems. That whole infrastructure qualification step is now automatable, and arguably you no longer need to do verification steps afterwards if you've already got that pipeline in place and an immutable production environment because you've already tested the tooling and proven that whatever you feed into your CloudFormation template is what is getting deployed. So you've quickly sped up that verification of infrastructure.

Think about how we discover compliance issues in your systems today. It's usually during an audit, where the auditor asks some question and you have an "oh no" moment—we missed something. It's a little late. So we want to shift towards automated monitoring, watching for drift. We want to be able to detect any compliance issues well in advance of any audit. Then we get to execution. This is where the rubber meets the road, and I'll hand it back to Tom.

Pillar Four: Execution Strategy and the 90-Day Transformation Sprint

Thanks, Ian. I'm excited about this. You bring together the culture of the organization and the mechanisms. Really, what we're trying to build is a solution that allows you to use your current requirement tool—maybe it's JIRA, maybe it's something else. Just do the documentation in there. Use your architecture tool, a variety of different tools. Document your information inside of there. Having the automated pipeline that captures the information, executes the automated test, captures the evidence of the automated test, and inputs all of that into compliance documentation automatically.

Your engineers are already doing these activities of designing your software, gathering requirements for your software, building your software, checking in code for your software, testing your software, and getting the results from the test. These are things that they should already be doing every day just to write your software. And if you do it right, all of that can then generate the compliance software or the compliance capabilities that we need so that we can execute all of this at speed.

We've built a culture where teams hopefully want to automate as part of this. You've structured the organization the way you want. Now comes the part that feels scary—executing, putting this into production. But here's what changes: you're not hoping it works. You know this will work because this is how you've been writing the software and how you've been approaching it.

We've seen teams spend six months validating their validation approach. Congratulations. They want everything perfect before they start anything at all. And I'm not telling you to be reckless, but their systems are accumulating debt, their competitors are outflanking them. And the cost isn't just in time; it's in the momentum of the things that you never even get a chance to do.

Ninety days is the transformation sweet spot for where we want to target—long enough for real results, short enough to maintain focus. You don't have to be great to start, but you must start to be great. This is something that you will iterate on, as Ian broke down for you. Small incremental steps for your teams to take, fast enough that you can't overthink this. Give your team short-term deliverables. Even though we might be going for a ninety-day project, I want to see something today, I want to see something tomorrow. Give your team the impetus, the drive, the energy to innovate and not overthink it.

Start with what you control. Maybe get your Git signatures working correctly, as Ian mentioned. Set up that first compliance test and build that simple dashboard. And each week as you iterate over this, you will build increasing amounts of confidence.

Consider where your team spends time today on manual compliance work. Go after those things religiously. Developers waiting for approvals—if I ever heard the term "I need wet ink signature on a paper," I would lose my mind.

I'm trying to push something into production, but we can't put it into production because you need to get someone to sign off on it, and they're at their daughter's softball game. We live in a digital world. How can we evolve past that and move past these things? It's through automation, through these automated capabilities.

Different stakeholders care about different aspects of this. Your CEO likely thinks about your market position, competitive philosophy, and velocity. Your CFO wants to understand the cost, the savings, and the risk exposure. Your engineering leaders want to know how they can go faster and innovate. Unfortunately, the quality teams think that they're going to lose control in this automation. But what I've experienced and seen is they actually gain more control because they have input and control into the process and the ability themselves to directly influence what happens.

I've seen teams get stuck waiting for the perfect automation plan. They want to solve everything at once. Others buy expensive tools. What actually works, going back to what Ian said, is to pick that one issue, get it working, and then let the success spread those small visible wins. We've done this in every transformation we've led. This is no different than how this happens.

Scaling too fast can also be a problem. You get excited after those early successes, but you want to roll it out everywhere. All of your compliance is going to change the whole organization. Slow down. Each team will surface new requirements and new issues. Move progressively, move with purpose, move to that 90-day target. But don't do it to the extreme.

The temptation is to scale too fast. But the teams that rush into those organization-wide solutions often hit a problem that they can't solve. One team learns how to actually start that operating three to five. Your next teams show whether or not your approach will actually scale and whether or not it'll work. Doing it once is good. As Ian mentioned, get the momentum, but I've got to push more people to figure out how well this scales, and do that thoughtfully and deliberately. Before you get to that organization-wide rollout, you're going to know that this is working when certain things are happening.

Teams outside your pilot will ask how they can join what you're doing. It happened to me. I had teams coming up to me saying, all the cool kids are doing this new compliance documentation and they love it, and do I become a cool kid? Your weekly demos will grow in attendance without you requiring people to come, and your auditors will shift from skeptical to curious. I had my auditor come up to me and say, when you started this, I didn't think you were going to be successful. I didn't believe in it, but I am impressed with where we are, and I wish I'd participated in it from the beginning. We need to bring those minds and those people along with us. As Ian mentioned, bring them into the process and not have them sit outside.

I know a common fear is that your regulators won't accept automated compliance. But modern regulatory guidance encourages this automation, encourages using this tooling. You gain more visibility. I had so much control and visibility. I knew exactly what we deployed into production, why we did it, the requirements for it, how it was designed, how it was tested, and the results of those tests. Every single time we put something into production, and when I talk to my auditors, I ask, what else do you want? Assuming it resulted in quality, which is the end game. That's where we want to get to.

Overcoming Objections and Bringing It All Together

You're going to hear objections. Everyone who tries this, in my experience, and Ian probably can say the same thing, has heard the same things. We tried automation before, and it didn't work for us. But that's usually because the tools came first without thinking of the workflow and the process. Ian and I gave you a little insight into how you can capture requirements in JIRA and move that through the process. Each one of you has a unique process. We're happy to work with you on that. You have that unique process because you're all unique.

So start small and iterate on this. The fear of breaking compliance is real. Be thoughtful and careful—you're not switching this overnight. I ran mine in parallel, so I still followed the traditional waterfall, word-based documentation and all those things. While I implemented this automated process, I showed it not only to my internal compliance teams but also to the external compliance teams. The old way came up with this, the new way came up with that. When we pointed to whether they were documented controls over the environment exhibiting quality systems, they were the same. It took time. I had to keep going back, keep showing them, keep demonstrating. Eventually they said, "Yeah, yeah, yeah, we're good. Get rid of that other stuff." You are going to go through these same things.

So we've covered a lot. We've talked about culture, organizations, mechanisms, and execution. Each piece in this puzzle matters, but together they create something bigger. Culture makes the teams want to automate. Help them understand why we need to move through compliance theater and toward quality excellence. Build that transformation army as Ian talked about, and show those working systems. This isn't about slides and beautiful presentations. It's about showing things at work and having those KPIs—a great name and shame board. Here's the teams that have implemented fully automated compliance. Here's the ones that haven't. No one wants to be on the bottom end of the leaderboard.

Then move into the organization. We want to get from silos to squads. We need ownership of this. I used to tell my compliance people their job was not to make sure I wrote compliance software. Their job was to ensure that I delivered compliance software into production. We need them to all have the same goal and objective—the engineering teams and the compliance teams—and we need to empower these teams on how to do it. But we can still do that by having control.

Then we need to move to the mechanisms. As Ian mentioned, every tool and system that you're using today is probably creating evidence and proof of how it's being operated. Implement controls over that. Your pipeline then becomes your validator, your control system. My pipeline was under the most change control out of anything I had, because my pipeline was the way that I guaranteed that all of my systems worked correctly. Get into that self-documentation and extract that information.

Then we want to move on to execution. Focus on that 90-day sprint, but focus on how you can have that small value and incrementally grow as you do this, as you run these in parallel the traditional way and the new natural compliance way. Ultimately, I think you'll see that you have a lot of success in this. I appreciate your time here today. These QR codes as well as the information up there show the contact information for Ian and me. We would both be happy to continue the conversation with you to answer any further questions as you begin on this journey. We will also be spending some time here afterwards after the presentation if you want to come up. If any of you have any questions, thank you very much for your time. I know it's been a long day, and thanks for hanging out with us here at the end of the day today.

---

; This article is entirely auto-generated using Amazon Bedrock.