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 of Foundation Medicine) and Ian Sutcliffe (Principal Tech Strategist) present a framework for achieving compliance through software excellence rather than documentation theater. They introduce "natural compliance" where quality emerges from engineering practices, not manual processes. The framework consists of four pillars: culture (shifting from compliance to quality mindset with weekly demos), organization (embedding compliance experts in product teams, eliminating silos), mechanisms (automating testing, using CI/CD pipelines as validators, leveraging existing tools like JIRA to generate compliance evidence), and execution (90-day transformation sprints with incremental wins). They emphasize that FDA and regulators now encourage automation over documentation, and provide specific metrics showing compliance costs ($30M annually in financial services) and the 2.71x penalty ratio for non-investment. The approach enables daily deployments while maintaining regulatory compliance through automated controls and immutable evidence.

; 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." It's a super exciting topic. Actually, I think it's a little bit exciting. This guy here with me thinks it's even more exciting. 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, pharmaceutical. I've been anything with architect in the title.

Wonderful. Well, let's go ahead and get started. So this is a topic that I'm sure you're all, like I said, super 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 they are things 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? So 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, on how software excellence makes compliance more of a natural outcome of your activity.

Before we dive into solutions, we need to acknowledge, well, maybe an uncomfortable reality. The compliance approach that we all, and I'm going to group you in with me here, that we've all inherited, obviously wasn't designed for modern software, but it is being ruthlessly applied to modern software. So let's face some uncomfortable truths about what that's costing us maybe, but the implications, and I want to start with a question that might make you uncomfortable. What if our compliance teams are actually, well, what if they're solving the wrong problem? What if those hundreds of hours that we're doing and trying to document compliance, what if we're just chasing shadows? What if compliance could actually emerge just solely from that good engineering?

So 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 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 them in a different way.

So let me dive into the details on how these approaches, well, maybe how they differ a little bit. 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, well, you build it, you create it, and then you scramble at the end. Now maybe you guys are better than I was with my teams, but you bolt compliance on in the end. It's kind of like our souped-up car there over 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, and I won't go so far as maybe to say it protects little, but it doesn't actually drive the results that we want to have. This natural compliance way builds excellence in. Compliance is engineered into the process and the workflow of doing software development.

The Hidden Costs of Traditional Compliance: A Trillion-Dollar Problem

And here's what's transformed our thinking. These aren't competing priorities: speed, quality, 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.

In healthcare, it's a trillion dollars yearly of 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 it's getting worse.

98% of companies report that their cost of compliance is going up. 61 billion dollars just in the United States for financial crime compliance. 42% is labor costs, people doing the manual work that we could have systems doing. This trajectory is just not sustainable, not only economically but from an innovation standpoint 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?

We can't afford not to transform and to make these changes, and 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, 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. Theater. But the reality is, software's continuous.

It's not a photograph, it's a movie. It deploys. It should deploy daily, be updated on a regular basis. By the time we validate and document the software, it's already moved on, or 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. Love my auditors from the FDA. Class three regulated device. I'm sure many of you experienced the same. I talked to them and I said, you realize you're having me spend more time proving to you that I have good quality than actually investing in good quality. Now the good news is we didn't have a quality problem at Foundation Medicine, but it was so far out of balance and we're seeing them embrace this approach. FDA is moving towards this least burdensome approach. They prefer automated 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, while in some cases they're still validating, amazingly, quarterly.

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 Ian and I are going to take you through how you can adopt some of these practices.

The Four Pillars Framework: A Pattern for Achieving Natural Compliance

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. I mean 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. Unfortunately, if you miss one, everything's going to fail. First is culture. We've heard it so many times in any transformation. The 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.

Let me walk you through each one and how they build upon each other. You might think this is great, maybe it works well in the pharmaceutical industry with the FDA, but every regulated industry faces this same exact challenge. Healthcare drowns in documentation, financial services in their validation. 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 mechanism elements to help you understand how we can achieve that natural compliance. Ian, I'll turn it over to you.

Attributes of Progressive Organizations: From Documentation Theater to Automated Evidence

Thank you, Tom. All right, so as Tom said, we have developed this framework. AWS likes frameworks. You may have heard of the Cloud Adoption Framework, the Well-Architected Framework. We like these frameworks. Let's cover some of the foundations first. Hopefully this will give you an idea of why we're developing this framework and some of the benefits we're hoping that you can gain from it. Again, this is not theory. This is work we've done with numerous customers, condensed from that experience. There's no accelerator for experience, and we've come up with these assets.

Let's just look at some of the attributes of what we consider one of these more progressive organizations. First thing, separation of concerns. What we see, one of the main problems is this combination of quality product quality teams and IT quality. We need to separate 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. That's where we collaborate. Those two teams get together, put their heads together, 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. You have a production line where product quality was influenced by consistency of the process. You log the processes, and that ensures a certain level of quality for that product. But in IT, every product is different. Every IT system, every product has different architectures and different technologies. So 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. Again, shifting away from manual processes and document-centric processes to start leveraging the tooling that any self-respecting IT engineering team is already using today. What we want to provide these development teams is what I'm calling freedom in a box. You provide them this environment in which they can operate quickly and efficiently. They can provide business value and focus on delivering that business value without really having to worry about compliance all the time. Try and take that lift off their shoulders.

A few more attributes. Shift left. In a lot of traditional IT organizations, that compliance work is kind of late in the cycle, in the development cycle. It's in the testing phase. We want to try and shift as much of that up left. You'll see from regulatory agencies like the FDA that this idea of 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. Too often I see the IT teams creating the system documentation as part of their SDLC, but there are then still SOPs around these things. If you think about it, when you want to control a manual process, you have an SOP, fine. As soon as you automate that process, all of that information is transferred into the system documentation, the workflows, and the design documentation. In those situations, you should be retiring the SOP. But still we see the two being maintained in parallel. Capture artifacts.

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

We want an immutable production environment. We want to prevent people from directly accessing production accounts through command line interface or the console, because 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. So those are some of the attributes we're looking for, and that's why we put this framework together.

Now the benefit is that all of these things get improved. Speed increases by eliminating handoffs between teams. Quality improves by finding issues early rather than fixing them late. The 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 the talent stays or is attracted to high performing engineering teams. They get to focus on the cool stuff rather than worrying about compliance.

But there's a cost benefit. I mean, we've known this 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. We've known this forever. So 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 are fixing things in production. The typical compliance phase, though, is tail end of this. 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 a higher cost already. We want to shift that left.

Now many of you here already have a gold mine of information. I think pretty much any engineering team these days is using tooling. You know, JIRA for requirements management, Confluence for documentation. You've got CI/CD pipelines, you've got 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, and stop creating Word documents when you can manage everything in this tooling. So 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. So the automated controls, the immutable evidence, and now that equals trust. We're trying to change the mindset.

Culture: Building a Transformation Army Through Weekly Demos

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, great architecture, but seventy percent of transformation efforts fail because of culture. So that's the first pillar, that's what we want to tackle first, the hardest part. And this was confirmed by McKinsey. They did research again confirming seventy percent of transformations fail, and the reason is not technology, it's culture and resistance. So 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. So 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. So 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 re:Invent, start to reinforce this with your teams.

Start to change their thinking. So we first need to create a transformation army, but it's a tiger team. It's a small team. We want to find those champions with the willingness and eagerness to go out, try, and help with this transformation. I think it's roughly 20% that love automation. If they do something twice, they will automate it. About 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.

Their mission, this team's mission, 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. Now this is a practice that has transformed dozens of cultures. It's proven to work. Again, we've worked with a lot of customers, and it's around demos. Weekly 30-minute demos showing something working. A working system will build trust faster than slides ever will. Actually working systems.

So start with your team in the first few weeks. Try and build some of these automations. In another few weeks, show it to your management. Maybe around 12 weeks, actually invite auditors in. Show them what you're doing. Get them on board. Now 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, demo attendance, but celebrate them. Celebrate those monthly wins. Promote these champions. Have it improve their career. Encourage them to start adding to this.

Again, the goal is to make compliance so automated that nobody really thinks about it anymore. That may sound kind of contrary to this whole career progression, so you need to celebrate these wins, these automations. Link their careers to these. Okay, so we've covered culture. Hopefully we've nailed that. We've got people. The mindset is changing. We then need to match the organization to it.

Organization: Breaking Down Silos and Embedding Compliance Experts in Product Teams

This demo culture creates something pretty powerful, which is 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, turf wars, and try and bring them together. 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 mind 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 none of these handoffs between organizations. Same concept 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. They're 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, you know, we mentioned waste or lack of efficiency. The traditional organizational structures often slow things down, kill speed and innovation. They create waste because every kind of handoff introduces delay, two to four weeks. Information gets lost. It's like playing Chinese whispers. It's not working. There we go.

Every handoff degrades information and introduces waste. When your compliance team sits in one building and your development 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's no handoff anymore. The compliance engineers sit in the standups with your development teams. As part of their career progression, maybe they also start to write code. Start small. They look at automation and try to automate their own checks. They really start to get into this automation, automation, automation mentality. The old review gates start to disappear because it's all built in.

As I said, 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 in this case. But 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, creating this cycle much smoother than this old school handoff approach. Now I mentioned earlier things like the cloud adoption framework and product-based operating models. A foundational piece is the platform team. An example is to create your landing zone. You have a cloud center of excellence sitting around that. The platform team is an enabler of multiple development teams.

They start to take some of that compliance heavy lifting off the shoulders of development teams and build capabilities into the underlying platform. This could be account vending and baselining your accounts. You've got that freedom within the box because you are giving them an account that's already got all the guardrails around it. You can create building blocks, so these are pre-approved infrastructure as code like CloudFormation templates made available to them through a service catalog. It's things that they can start to use, shifting towards self-service. The platform team becomes a great enabler of this.

There's going to be some upskilling, I mentioned those compliance engineers. We need to establish some training paths for them, again linked to their own career progression. Those compliance engineers that used to just handle documentation all of the time start to shift towards becoming 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're talking about.

Here's an idea of your first week. When you get back to the office on Monday, you're fully recovered from re:Invent, 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's a commit in your Git repo. Create that first compliance test. Start to collect that evidence on the Wednesday with basic dashboarding. Now that you've got 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've got culture done, got the organization hopefully aligned. Something great happens then. The technical work and generating this evidence starts to become natural. These aren't theoretical concepts. They're patterns that are working in production today with many of our customers. Let's look more into these mechanisms.

Mechanisms: Turning Your Tool Chain Into a Compliance Generator

Let me 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 development team's daily work through proper automation. However, in cases where you do manual testing, your validation cycles never actually catch up to your rate of delivery. So by the time you finish validating, your systems have already changed. Tom mentioned this earlier.

It's the same even if you buy off-the-shelf software. You install it, you start your validation cycle, you report a bug to the vendor, they have to fix it, patch it, and you've got to restart your cycle again. It's just this never-ending pain of validation never keeping up with the pace of change. So we need to change that. When you get to the audit, every audit becomes this archaeological investigation into piles of documentation that's already out of date. It's painful.

We really need to encourage test-driven development, test automation, anything to make testing faster so that every commit, every release, is getting validated every single time. Requirements in code may be a step too far for some, but really the message is that requirements don't need to be in a Word document. They don't need to be in any user requirement specification in a set template format. You could at least store your requirements in JIRA and manage them there. Demonstrate control over your requirements management using the tooling.

If you are having to extract your requirements to create a document, something is wrong with your process. Talk with your engineers, your quality engineers. Every time your code changes, you're going to have to update the requirements. You could actually use them. You've probably seen it in the hallways. Anything to do with Gherkin, spec-driven development is a great new tool. You should really look into it where you are capturing the requirements in a specification. Gherkin is helping you develop those. Again, requirements are embedded in the code almost.

What's interesting is that the regulations have been around forever. They haven't changed in many, many years. But what they're actually asking for used to require specialized systems to capture those audit trails, to 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 and not using the capabilities in the tooling we already have. So we need to shift.

You are already generating all the evidence. As we mentioned, that tool chain from requirements management linked to your test management tools, CI/CD pipelines that are telling you what was deployed and when, defect management tools to automated testing, you name it, 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. So 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 trace 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. So start to inventory what you have and start to pull that together into one place with the goal of auto-generating reports if need be 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 thing. Again, it's 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. What I've described was we all do it with code, do it the same with infrastructure. Now we have a CloudFormation template, we do a pull request, it gets reviewed, approved, triggers a pipeline, gets deployed through CloudFormation or Terraform, your choice. But 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 in 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, because you've already tested the tooling and proven that whatever you feed into it in 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 sugar moment, we missed something. It's a little late. So we want to again shift towards automated monitoring, watching for drift. We want to be able to detect any compliance issues well in advance of any audit.

Execution: The 90-Day Transformation Sprint and Scaling Strategy

Then we get to execution. This is where the rubber meets the road, and I'll hand it back to Tom. Thanks Ian. I'm excited about this, and 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, 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 a compliance documentation automatically.

So that your engineers who 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, 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.

You've built the 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, 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 again, 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.

So 90 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 90-day project on it, I want to see something today, I want to see something tomorrow. Give your team the impetus, the drive, the energy on this to innovate and again, to 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, that manual compliance work. Go after those things religiously. Developers waiting for approvals. Gosh, if I ever heard the term I need wet ink signature on a paper, again, I'll lose my mind.

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 this automation, through these automated capabilities.

You see, different stakeholders care about different aspects of this. Your CEO likely thinks about your market position and competitive philosophy and velocity. Your CFO wants to understand the cost and the savings and the risk exposure. But your engineering leaders want to know how can we go faster, how can we 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 and things. What actually works, again going back to what Ian said, is pick that one issue, get it working, and then let the success spread through 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, and you want to roll it out everywhere across your entire 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 organizational-wide solutions often hit a problem that they can't solve. You see, one team learns how to actually start that operating. Three to five of 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 you've got to push to more people to figure out how well this scales, but do that thoughtfully and deliberately.

Before you get to that organizational-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 how 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 and 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. And 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, the results of those tests, every single time we put something into production. And when I talked to my auditors, I said, what else do you want? I mean, assuming it resulted in quality, right, which is the end game. But I was like, what do you want? That's where we want to get to.

Overcoming Objections and Bringing It All Together: A Roadmap to Natural Compliance

But yeah, 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, 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 bit of 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.

But you have that unique process, and that's because you're all unique.

So start small and iterate on this. The fear of breaking compliance is real, so 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 not only my internal compliance teams but the external compliance teams that the old way came up with this and the new way came up with that. When we pointed to whether or not they documented control over the environment and exhibited quality systems, they were the same.

It took time. I had to keep going back, keep showing them, keep demonstrating. Eventually they said, "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, so help them understand why we need to move through compliance theater to 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, like a name and shame board. Here's the teams that have implemented fully automated compliance, and 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 probably is 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, 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. Thank you very much.

---

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