Buying vs. Building Compliance Automation Tools

Kaila Mathis: Welcome, everyone. Today's topic is buying versus building compliance automation tooling — a decision that every organization faces as GRC and security teams look to scale their programs, and one that comes with a lot of nuance. You can build internally or invest in third-party tools, and both have real benefits but also real trade-offs that we will get into today.

Before we get started, I wanted to give a quick thank you to our guest moderator, Alan Luk. We are really excited to have him leading this session. Alan brings a ton of experience across GRC and compliance, and he joined us back in February to lead our session on making cyber risk board-ready, which was one of our favorite conversations to date. We are really happy to have him back.

We are also very excited to be joined by an incredible group of panelists: Jeffrey DeNardo, Pierre-Paul Ferland, and Ayoub Fandi. Each of them brings strong experience on this topic, and Alan will let them introduce themselves shortly. For anyone joining us live, feel free to drop your name or LinkedIn in the chat — we encourage everyone to connect with each other, with Alan, and with our panelists. We will also make sure to cover audience questions toward the end. With that, I will hand it over to Alan to kick us off.

Alan Luk: Thank you, Kaila. Hey everybody, I am Alan Luk, playing moderator once again — and it is becoming a favorite role of mine. I just get to ask guests questions and listen to them talk about their experiences, so I feel very honored to be doing this again.

Today's topic is build versus buy for GRC tooling. A lot of GRC teams today are under pressure: automate faster, scale across frameworks, stay audit-ready, do more with less. One of the most strategic decisions leaders need to make is whether to buy something out of the box and make it work, or build something internally when buying does not quite fit. We have three panelists with a wealth of experience who are going to talk about their own experiences — doing one, the other, or a hybrid — and discuss the real trade-offs: cost, audit defensibility, scalability, integration, tech debt, long-term ownership, and more.

Without further ado, let us get right into it. Panelists, why do not each of you introduce yourself briefly, share where you are working, and whether your organization has leaned toward buying, building, or a hybrid approach to compliance automation. Let us go with Jeff, then Pierre-Paul, then Ayoub.

Jeffrey DeNardo: Greetings, everybody. I am Jeffrey DeNardo, director of GRC at the Hershey Company. We have typically leaned much more toward the buy side of things. Part of that is because we do not have the biggest development shop at Hershey. My view and my leadership's view has always been that when it comes to GRC tooling, it is not rocket science — these vendors have already gone through the trials and tribulations of building these platforms. So we have generally leaned toward buying something off the shelf. From my perspective, it gets you to value a little bit quicker, which is something we will dive deeper into as we go.

Pierre-Paul Ferland: Greetings, everyone. I am Pierre-Paul — you can call me Pepe. I am the GRC manager at Coveo, which is Canada's largest AI company. Our story is interesting because Coveo has been maintaining a SOC 2 attestation for over ten years — since 2014, which actually makes it twelve years. At the time they achieved SOC 2, it was a fairly novel thing, and it was Salesforce that asked Coveo to do it. If a compliance automation platform had existed back then, I am pretty sure the CTO would have gone that route. But there was no such thing, so they went with a build approach almost by default.

When I inherited the SOC 2 program in 2019, we had a weird hybrid of custom-built tooling and spreadsheets. I maintained that for a while until I got fed up with the whole thing and we moved to a more buy-oriented approach in 2024. So I am the buy person on this panel — with a lot of hard-won context about why.

Ayoub Fandi: Hello everyone. I am currently the GRC automation lead and GRC engineering lead at GitLab. We went down the build path internally. I manage software engineers, which makes it a bit easier to pursue that route. We have actually built four tools in just under four years. In previous roles — at Salesforce, and at a startup where I was doing something closer to Jira with spreadsheets and custom workflows — I have experienced both sides. I can argue either position today, but I lean build. I think it is genuinely a spectrum and I am looking forward to hashing this out with the other panelists.

Alan Luk: I am not a panelist so nobody really cares about my opinion, but I work at Microsoft, so obviously we build everything. Our ego is too big. We are a software company, so I am also on team build.

All right, first question for you all. What stage was your compliance program in when you said enough is enough — we need a compliance automation tool, whether we buy it or build it? And what were the main problems that having a tool would actually solve?

Jeffrey DeNardo: At Hershey, I think every GRC team reaches this point: you believe you can manage everything via Excel spreadsheets and manual evidence collection, and then you hit one audit cycle and realize very fast that you need a tool. That is exactly what happened to us. Our SOC program was a bit of a mess, so that was the primary problem the first tool solved.

My recommendation to anyone starting down this path: do not try to boil the ocean. Pick a very small, high-impact use case, something you can solve quickly and show a clear return on investment — especially because these tools can be expensive upfront. We automated our SOC controls, it instantly showed value, and that enabled more investment to start scaling the program. We started small, demonstrated the return, and slowly grew from there. Where we are now is looking to enable continuous controls monitoring — and we are taking the same approach: start with the controls that information security owns, show the return, and then expand. Excel spreadsheets were fine to start, but picking something small and growing it really, really helps.

Alan Luk: Jeff, quick follow-up: who are the main users and contributors to the GRC tool? Is it primarily the GRC team doing everything inside the tool, or are domain teams and control owners also finding benefit?

Jeffrey DeNardo: Absolutely both. The initial lift was a real relief for my team — no more managing evidence tracking in a sprawling spreadsheet. But it also helped control owners significantly. The automation sends them emails when things are coming due and reminders as deadlines approach. Previously, all of that responsibility fell on the GRC team. With the tool, a control owner can just pop in, grab a screenshot, upload it, and be done. They do not have to worry about following up to make sure the auditors received it. For IT leadership, they could run a report and see everything past due and everything completed at a glance. It was a win-win for everyone, not just a relief for GRC.

Alan Luk: And you are still on that original tool?

Jeffrey DeNardo: We are, and we are experiencing some growing pains — that is actually a topic for later in this session.

Pierre-Paul Ferland: My story is pretty similar to Jeff's. For us, two forces were at play. The first was ISO: Coveo got ISO 27001 certified in 2023, and the intention was to build on that — one new certification per year. I needed a certification machine that could get us through new ISO extensions quickly and at scale. I had been through ISO audit preparation with manual spreadsheets and hand-drawn mappings in 2022, and it was incredibly painful. The second force was running lean. We wanted a small, highly efficient GRC team, and we believed a platform would help with efficiency, knowledge gathering, and eliminating repetitive work.

The platform has delivered on both fronts. It integrates directly with our auditor — I can upload a screenshot, the platform's built-in AI recognizes and describes the screenshot, I hit ready for audit, and it goes straight to the auditor. That eliminates a huge amount of grunt work. The old custom-built automation, by contrast, required booting Docker in a deployment environment, impersonating an IAM role, and half the time it would not work because you had to update thirteen dependencies. I was not willing to train my team on that.

Alan Luk: Similar question, Pepe — are other teams benefiting from the tool, or is it primarily an internal GRC workflow tool?

Pierre-Paul Ferland: This is where I differ a bit from Jeff. I did not want to force a supplemental UI on top of developer teams. For me, the platform is more about the GRC team's internal routine rather than something that brings the whole company together on compliance. My preference is to let people work where they already work and have the platform pull the information from there. It is a strategic choice, and it works for us — though I may change my mind down the road.

Ayoub Fandi: At GitLab, the challenge was that as we cycled through different commercial solutions, we kept running into the same problem. A lot of platforms have connectors for common tools, but the connectors are extremely shallow compared to what you actually need in practice. GitLab uses GitLab for project management — where most companies would use Jira or Trello or similar platforms. Most compliance automation vendors cared about basic things like checking for merge request approvals in CI/CD, but we needed to go three or four levels deeper than the average customer. Our GRC team is also fairly large — around twenty individual contributors — which meant our use cases were far more complex and our testing approaches varied across the team. We kept running into limitations that were invisible in demos but obvious in production.

The broader issue was that automation platforms at the time were designed for smaller, leaner teams or non-core GRC buyers. We could not get the automation depth we needed from traditional buy options, and we could not get the flexibility we needed from automation-focused buys either. At some point we just decided: if we have the resources and the engineering capability, let us build something that actually fits.

Alan Luk: Let us talk about cost and ROI. How did you propose the return on investment to leadership? What is the true total cost of ownership for build versus buy? And what are the costs that most teams miss that come back to bite them later?

Jeffrey DeNardo: The biggest thing to understand when you bring these demos in and start POCs is that you are seeing best-case scenario. Every module is working, every integration is perfect, and it looks like it will solve the world's problems. The reality is that some of these tools, depending on their size and complexity, can take a year or more to reach that shiny demo state. So start with a small, concrete target. Show instant feedback and a clear return to leadership. You are not going to automate every control at once or implement every framework overnight — it has to be a slow progression with a roadmap. And it never really ends: as soon as you think you have gotten there, something like AI comes along and there is a new shiny object to chase.

Hidden costs compound over time. Once a tool is stood up, you still have to refine it, build or activate all the connectors, and integrate it with your other tooling. Understanding that from the start makes the journey easier.

Pierre-Paul Ferland: For us, the ROI story was classic for a software vendor: we needed to demonstrate trust to our customers, and a trust center was the vehicle. We were able to reduce back-and-forth with salespeople about document versions by around 80%. Using the platform as a sales enablement tool reframed the whole budget conversation. The pitch I made was: I want a certification machine that gets us one new certification per year without adding headcount. That is an easy sell when security is part of your sales motion.

On the cost side, there were some surprises we had not anticipated. The most mundane one: rotating API keys. We have around sixty integrations into our platform across many different teams. Every few weeks there is a ticket to rotate a key somewhere — for a Snowflake service account that expired, for another integration that needs refreshing. It sounds small but it adds up. The other issue was scale. We process around a billion queries per day and have thousands of EC2 instances running in production. At that scale, the GRC platform's evidence gathering sometimes struggles — and you cannot fully test it in a sandbox because running tests against that many resources would break the sandbox. You cannot run a POC in production either. So that gap is genuinely difficult to close.

Ayoub Fandi: On ROI, I think about two main avenues. The first is tying compliance directly to revenue — for example, we can say that out of a certain ARR figure, our team was involved in enabling roughly sixty percent of it. That framing works once or twice, but it gets old. The second is compliance as a direct sales enabler: getting PCI opens a new industry, getting IRAP opens Australian regulated government business. We tie certifications directly to Salesforce opportunities, so we can show exactly which deals were blocked and what certification would unblock them. That gives leadership a specific number rather than a vague contribution claim.

On total cost of ownership: for build, the ongoing maintenance is the dominant cost. Edge cases you did not anticipate keep surfacing. When things break, you need an on-call rotation, a ticketing system, and a way to triage what is high priority versus what can wait — especially during audit season when breakages are the most painful. For buy, integrations are typically the hidden cost. Getting them to the depth you actually need is often much harder than the demo suggested, and the more complex your environment, the less likely you are to get full value out of the box. Then there is the often-forgotten cost of the evaluation process itself: running POCs, sandboxing with limited context, onboarding, and potentially offboarding when it does not work out. All of that is real time. If you are running POCs with four or five vendors against a detailed requirements matrix, someone on the team has what is effectively a part-time job for months.

Alan Luk: Let us talk about outgrowing tools. At what point do you hit a roadblock and say this served us well when we were smaller, but we need something different now? And is hybrid the right end state, or just a transition phase?

Jeffrey DeNardo: I think it is a transition. There are two sides to outgrowing: you outgrowing the tool, and the vendor outgrowing you. When you buy something, you need to make sure the vendor wants to grow with you and can support your trajectory. If they cannot, that is a red flag. We have experienced situations where roadmap items we needed were either not supported or were being built faster by smaller, more nimble companies that could iterate more quickly.

The key is knowing your end state from the beginning and sharing that roadmap with the vendor up front. You need to know that two years down the road they can still support your needs. Multi-year contracts save money, but only if you are actually growing together — not stagnating while the vendor moves in a different direction. Make sure to have explicit conversations with vendors about where you are now and where you want to be. A lot of GRC tooling is not rocket science, and new companies pop up constantly. Smaller vendors can often move faster and even jump on calls with you to understand your specific needs in ways that larger vendors simply cannot.

Ayoub Fandi: The SaaS vendor relationship is a bit of a catch-22. When the vendor is small, you represent a bigger share of their revenue, which means they listen to you more and you can genuinely influence where the product goes. As both of you grow, your share of their revenue mix shrinks, and the use cases of their other customers start to dominate the roadmap. So the company you loved at the beginning becomes a worse and worse fit as your complexity grows, even if their product is genuinely improving.

At some point, you have spent all this money, and you have also indirectly done free development for the vendor — building integrations they did not have out of the box using your own engineering time. That engineering time could have gone toward building something you own. At GitLab, that realization pushed us toward building. But building has its own pains: ongoing maintenance, unexpected edge cases, and on-call burden during audit season.

The question we ask now is: if I am well prepared and I know exactly what the pains are going in, can I make an informed decision? Yes. The answer is different depending on your complexity, your team's technical capability, and how many of your core workflows the tool can actually support natively.

Alan Luk: Ayoub Fandi, how much of your assessment of a tool is based on how much works out of the box versus how much customization is needed from the vendor?

Ayoub Fandi: At GitLab, we mapped out all of our workflows in detail before evaluating tools: for control testing, here is the input, the process, the output; for risk assessments, here is how we pull data, how we assess it, and how it is consumed by different personas. The question we asked was: do the core workflows — the things that represent 90 percent of how we do GRC work — have a strong fit with this platform? If they do not, nothing else matters. A vendor will tell you in a contract that they will build a custom integration, and then the person who promised it leaves the company. If the platform is not designed around how your team actually works, they will not rebuild it for you, regardless of what the contract says.

The secondary considerations — a missing integration here, a different view there — are details you can live with. But if the core workflow fit is not there from day one, you cannot recover from that, no matter how good the AI features are or how nice the UI looks.

Alan Luk: A question that does not get discussed enough: how do auditors actually feel about the data and evidence coming out of these tools? Does it make audits more efficient, or do you end up spending more time explaining how the tool works?

Pierre-Paul Ferland: In the first year, you are not getting much ROI from the auditor relationship. The auditor has to figure out why they are receiving a bunch of CSVs and API outputs, and you cannot just send them a two-hundred-line Python script and call it evidence. What I ended up having to do was document the entire process: here is what a pull request looks like in GitHub, here is what you are seeing in the CSV, here is how the API request is made. It is basically like writing documentation for your own platform's code. The first year we transitioned, we had a new auditor doing the testing — so imagine being handed a set of CSVs about EC2 tags with no context. Of course they got confused. You have to create a document that shows a generic screenshot of what the console looks like alongside the API extraction that produced the CSV.

The upside is that once you have those documents, you can reuse them to train your team as well. It is a one-time investment that pays off going forward.

Ayoub Fandi: Automation platforms are often designed for smaller teams and non-core GRC personas, which means auditors were often baked into the product's assumptions. When you work at a larger company and bring your own auditors to your platform, there is a context gap every time — especially if you switch platforms but keep the same auditor.

What I care most about is how easily I can export data in formats the auditor can actually use. If the only export is API calls and JSON, that is great for GRC engineering but takes fifteen steps of explanation for an auditor to understand. You need CSV exports, well-structured testing sheets that mirror how you did things manually so auditors can match the automated approach to the familiar one, and historical artifacts showing how your testing approach has evolved.

The broader point I would make is that GRC teams work in this space 365 days a year. Auditors analyze environments for a couple of weeks a year. Before any automation platforms existed, teams sent CSVs over email and everyone was still employed and things still worked out. I care more about improving our internal workflows and how we collaborate with internal stakeholders for greater impact. Auditors are an externality of a well-run program — important, but not the primary reason to build or buy.

Alan Luk: Let us talk about green dashboards. A lot of the criticism of GRC tools centers on showing green checks that do not reflect reality — the watermelon problem: green on the outside, red on the inside. Is this an implementation error by GRC teams, or is it an inherent gap in out-of-the-box functionality that biases toward showing green even when things have not been fully validated?

Jeffrey DeNardo: Both. A lot of these tools do err toward showing things as green and compliant by default. An example we are working through right now: we are automating some of our vulnerability management controls, and we are approaching it by flagging a control as green if you have hit a certain percentage of your SLA. In reality, nobody ever remediates 100 percent of vulnerabilities. If your control is testing for full remediation, it will fail every single time — and eventually it becomes like the boy who cried wolf. Nobody pays attention because they already know it always fails.

But the alternative has its own problem: if you lower the threshold to 85 percent patching, the control is always green, and the 15 to 20 percent that missed their SLAs — possibly the most important ones to look at — get buried.

The onus is on the GRC team to explain why a dashboard is showing what it is showing. And there is a deeper issue: many auditors only want to see a sample of 25. If you are doing full-population continuous monitoring and testing 2,000 occurrences, you might see one failure that a sample of 25 would have missed entirely. Having that conversation with leadership — hey, this control technically failed because 1 out of 2,000 occurrences failed — is hard. But it is the right conversation. GRC teams need to make sure everyone has the full context for what the dashboard is actually showing.

Pierre-Paul Ferland: From the trust center side, you have to onboard every control domain with evidence before anything displays. Anyone can challenge you and ask for more evidence. So while it would be nice to be compliant by default, that is not the reality. You have to do the work to actually show the green.

Alan Luk: On the topic of out-of-the-box functionality biasing toward green — there is a well-known situation in the GRC world right now that speaks to this. A content policy alone does not make you compliant. The burden of proof should be on the GRC team to validate and justify a green status, not for the tool to default to it. Have you found that tools require you to do that validation work to earn the green, or do they hand it to you automatically?

Ayoub Fandi: The way our trust center works, nothing goes green until you have uploaded evidence and documented how the control is operating. Anyone can challenge that and request additional evidence. There is no hallucinating evidence — you either provide it or you cannot show that domain as green. Would it be great if we were compliant by default? Sure. But that is not where we are.

Alan Luk: Closing question for each of you. You all made the decision to buy at some point. If you had access to today's AI technology back then, knowing what you know now about GRC engineering as a growing field and the tools available — would you still have bought, or would you have built?

Jeffrey DeNardo: From a Hershey perspective, I think I still would have chosen buy. Our business is not that complex from a compliance standpoint. We are making chocolate and making people happy — we do not have the volume of certifications or regulatory obligations that a software company has. We can adapt our internal processes to make an off-the-shelf tool work for everything we need. That said, I fully understand why our other panelists might have made different decisions. Their environments are simply more complex.

Pierre-Paul Ferland: Honestly, if AI at today's level had existed when we were making the transition two or three years ago, I think I would still be vibe coding a GRC system with a bunch of MCP servers stitched together from a Claude desktop session, accumulating tech debt and producing something that looks like a Frankenstein monster. Probably broken, but still trying to make it work.

Alan Luk: Quick follow-up — how do you think your auditors would have reacted to a home-built, AI-stitched GRC system versus a tried-and-true vendor tool with its own SOC 2 and ISO certifications?

Pierre-Paul Ferland: It would have been the same confusion, but with considerably more skepticism.

We actually did build our current platform fairly recently, but that was before AI coding was truly capable — before roughly late 2025. Looking back, all the prep work like data flow diagrams, surveying, and documentation would probably benefit significantly from AI assistance now. I would still lean toward build in that context, but with two important caveats. First, the cost of code is going down — but intent is everything. If you have mapped everything carefully, you understand your tech stack, and you have someone on the team who can actually read and verify the code, the risk of vibe coding becomes manageable. The danger of AI-assisted building is producing code you do not understand. Second, the cost of tech debt is also going down — if you have spent time mapping your system well, you can then use AI to help fix the debt. So on both ends, I think thinking like a builder — even if you ultimately buy — ensures you understand your program deeply enough to make either approach work.

Ayoub Fandi: I would lean the same way. We built our platform before AI coding was good, and even now, the foundation still matters. Being able to move quickly with AI is built on having good governance and solid security practices already in place. We are finding that some of the gaps people did not bother fixing when they had policies — because it was low effort to ignore them — become very exposed when you put an AI agent on top of a flawed foundation. An agent can do more in a shorter amount of time, and the blast radius of those gaps is much larger.

I encourage everyone to go out and learn to build. Try vibe coding in your free time. Build a small agent. Understand what you are working with. And then make the buy or build decision with real context, not just from a demo.

Alan Luk: Well, that is the end of our session. Thank you so much, gentlemen. I really appreciate you taking the time and sharing your insights. I highly recommend connecting with each of them on LinkedIn — they are all happy to continue the conversation there.

Kaila Mathis: This was really great. The decision to buy versus build is clearly not one size fits all, and I appreciate everyone sharing such specific, grounded perspectives. Thank you all so much, and to everyone who joined us today — we hope to see you at the next one.