This is the first ever deep-dive on the newsletter (and probably in the whole GRC industry) and I’m super excited to host it!

As a practitioner, I always consumed a ton of technical and design deep-dives in the Product, Infrastructure and Engineering spaces. This is my attempt in building a similar approach for GRC so everyone can access for free to how the world’s best GRC programs are run.

No gatekeeping, no theories, nothing that doesn’t work in real GRC programs.

It’s a conversation where I ask questions about a GRC program, could be about everything, could also be only on a topic like GRC Engineering, risk, TPRM, etc. and then the leader answers and gives details about how they run things!

When I was looking for GRC leaders to be featured for the pilot deep-dive, Pierre-Paul said yes immediately. Most of you already know him through his great videos on LinkedIn and his sharp insights around the GRC hiring market.

As he has been running the GRC program at the same company for 6+ years, he has been through the thick and thin of scaling what was a small startup to a post-IPO company with everything it means! Where relevant I’ve also added links to previous GRC Engineer entries which map well to what Pierre-Paul is talking about.

I hope you enjoy reading through this piece and you connect with Pierre-Paul as well! Check out his blog also which has great posts around GRC.

PS: If you want your GRC program/team to be featured, please respond to this email :)

Coveo’s GRC Engineer Deep-Dive

Deep-Dive Table of Contents

1. Six Years of GRC Evolution at One Company

2. GRC Engineering Architecture for High-Velocity Deployments

3. GRC Platform and Tooling Architecture

4. Dogfooding Coveo's AI Search for GRC Operations

5. Multi-Framework Compliance Architecture

6. 75% Manual Work Reduction: Technical Implementation

7. Third-Party Risk Management at 400+ Vendor Scale

8. GenAI Product Compliance Architecture

9. GRC Engineering: Theory vs Practice

Six Years of GRC Evolution at One Company

Walk us through Coveo's GRC transformation from startup to $1.7B public company over your 6+ years there

Pierre-Paul: Coveo is a B2B SaaS company offering search, recommendations, and generative answering for customer service, employee portals, and ecommerce. Our journey has always been driven by customer demand. It began in 2012, when Salesforce and Coveo entered a partnership.

At the time, Salesforce required SOC 2, and our CTO, Marc Sanfaçon, treated it like an engineering problem. Compliance was automated from day one, with engineering owning security long before compliance automation tools became mainstream. As an early adopter of AWS, Coveo embedded an engineering-first mindset into its security posture.

From a GRC perspective, that engineering-driven foundation eventually had to evolve into a more traditional enterprise security organization as Coveo grew into a public company. I joined in 2019 to build the procurement function and establish third-party risk management. GDPR had just gone into effect, and like many SaaS companies, Coveo faced a sprawl of department-owned tools often bought with credit cards and secured only by passwords.

Over three years, we consolidated vendors, negotiated contracts, enforced SAML SSO, assigned asset owners, and introduced security and privacy assessments with data classification. ISO/IEC 27001 certification became our “carrot,” creating pull rather than push across the business.

Looking back, the biggest blocker was that automation remained confined to the Coveo product. If the same approach had been applied to HR, CRM, ERP, and other enterprise systems early on, we would have been slower at the start but far more scalable long term. Instead, silos between engineering and IT created duplication: multiple AWS orgs, IdPs, logging stacks, GitHub orgs, and CI/CD models.

GRC Engineering Architecture for High-Velocity Deployments

How does your GRC architecture enable 140,000+ annual deployments without creating bottlenecks?

Pierre-Paul: Coveo is cloud-native. We have no on-prem workloads, and from the start our product security has been built with an infrastructure-as-code, cloud-only mindset. That philosophy drove early choices that continue to define our security posture.

More than a decade ago, engineers embedded compliance checks directly in the release pipeline. “Certifiers” in CI and CD enforce mandatory requirements such as GitHub configurations, CodeQL and Dependabot remediation, container vulnerability scans, and antivirus checks.

Access management followed the same automated approach. Over time, engineering extended compliance gates to verify background checks and security training before access was provisioned. Later, the security engineering team added StrongDM to provide zero standing access across AWS SSO, EKS, RDS, and EC2 (via SSH and RDP), ensuring least privilege by design. You can read the full engineering deep-dive here.

In 2020, Coveo expanded focus to data engineering and privacy. On Snowflake, the DBA team implemented validation schemas, data masking, and tokenization, and more recently added automated compliance checks that produce daily reports.

Today, our attention has turned toward securing Coveo’s generative AI offering. Data scientists work in a dedicated, secured AWS account, building automated testing to detect hallucinations and prompt injection attempts.

GRC Platform and Tooling Architecture

Detail your technical GRC tooling stack and integration architecture

Pierre-Paul: I have always had a strong buy-over-build bias. Yet until 2024, much of our compliance work still lived in spreadsheets and documents. Our SOC 2 program was built in 2014–2015, long before tools like Vanta or Drata were mainstream. Highly customized, it made automation especially challenging.

Training was another pain point. We relied on an in-house LMS never intended for compliance, and I often resorted to Python scripts to patch gaps. On the third-party risk management side, our tool was a bundled add-on to a cookie management platform. It was inexpensive but never fit the long-term vision.

Meanwhile, I also worried Coveo was falling behind industry trends, lacking a modern, transparent trust center. Collectively, these gaps made clear it was time to move away from improvised solutions and toward purpose-built platforms even if it meant diverting budget from headcount.

We evaluated 4 “all-in-one” platforms with a promising AI roadmap. Ultimately, we chose Anecdotes for its API-level integration with Schelmann’s audit system. It was the only solution flexible enough to handle our highly customized SOC 2, with more than 250 evidence items from over 30 systems. Anecdotes’ “GRC as Data” foundation and plugin ecosystem gave us what we needed: normalized evidence collection, AI-enhanced context, and relief from maintaining brittle scripts, Lambda versions, and screenshots.

Today, 42 systems are connected, generating over 1,000 evidence items and supporting an automated compliance audit. Plugins let stakeholders deliver evidence from within their own workflows, a dramatic improvement over the “cat herding” of 25+ people required in earlier SOC 2 cycles.

Dogfooding Coveo's AI Search for GRC Operations

How does your GRC team leverage Coveo's AI search platform internally?

Pierre-Paul: Like any vendor, we maintain documentation and an internal FAQ to answer RFP questionnaires. We have a few hundred pre-answered questions and around 20 official documents, but the real challenge is maintenance. We don’t want to interrupt workflows by asking people to manually update us; instead, we want to capture information directly from where it lives.

That’s where Coveo comes in. Internally, we use our own platform (Coveo@Coveo) to search across enterprise systems and power generative answering. Think of it as “RAG as a service”: the engine always pulls the latest version of documents, wherever they’re produced, and generates an answer based on enterprise knowledge. For static content, a custom GPT works well. But when niche or fast-changing questions arise, Coveo lets us surface the freshest answers without sending long questionnaires to IT or engineering.

The same applies to our internal security policies. All policies live in connected systems, so colleagues can query them directly and get precise, generative answers tailored to their needs. Better yet, Anecdotes’ policy module consumes the same source of truth powering our trust center and internal workflows alike.

Multi-Framework Compliance Architecture

Your unified approach to managing SOC2, ISO27001, HIPAA, GDPR, and custom frameworks

Pierre-Paul: I’m never doing a gap analysis manually again. We used to maintain a massive spreadsheet covering all frameworks, and every year one analyst would spend a week or more just updating it. That work is now automated. Instead of starting from scratch, our vendor delivers a pre-mapped framework, already populated with our existing evidence and enriched with AI insights to highlight missing requirements.

The cross-evidence mapping within Anecdotes has been the biggest accelerator. Preparing for ISO 27701 and ISO 27017 took little effort compared to past experiences. When we pursued ISO 27018, I had to manually map control overlaps across frameworks over several days. With Anecdotes, the process is nearly instantaneous.

What’s still missing is a quantified risk approach, both within our internal processes and in Anecdotes itself. The platform doesn’t yet support it, so we’ve experimented with alternatives. Using a custom GPT trained on public industry reports (e.g., awesome-annual-security-reports) combined with our internal documents, we’ve been able to generate baseline probability and impact estimates.

75% Manual Work Reduction: Technical Implementation

Break down the technical architecture behind your 75% manual work reduction

Pierre-Paul: The biggest time savings with our GRC tooling has been ISO audit automation, where we now serve 75% of evidence automatically. ISO is still documentation-heavy, but we’ve eliminated the tedious Confluence → PDF → upload cycle. Evidence is synced directly, with version history enabled so auditors can review updates, and AWS evidence flows automatically into their platform. In theory, auditors could monitor Coveo in real time year-round.

One lesson learned: auditors need context, not just JSON. The simplest fix has been attaching a Confluence page explaining the environment, with console samples, alongside the automated extract. It rarely needs updates but bridges the gap.

Transparency does mean auditors find more issues. In a TPRM market chasing “perfect reports,” openness is deincentivized as gaps breed extra scrutiny and endless follow-ups.

Third-Party Risk Management at 400+ Vendor Scale

How does your TPRM program architecture handle 400+ vendors efficiently?

Pierre-Paul: Scaling remains our biggest challenge. Over the past year, we’ve experimented with custom GPTs to accelerate two use cases. The first is a “security screener companion” that scrapes a vendor’s publicly available information, evaluates it against 50+ criteria covering security, privacy, and responsible AI, and delivers a preliminary assessment to future asset owners. This way, they know upfront what to expect if they pursue a POC or purchase.

The second is a “SOC 2 reviewer”, built around ~30 predefined criteria. We still have copy-paste to do and the approach isn’t proactive. I don’t think GPTs alone can solve the scalability issue.

From my perspective, third-party risk management is both the most ripe for GRC engineering innovation and the most in need of it. (Ayoub: I wholeheartedly agree with this statement haha)

GenAI Product Compliance Architecture

Managing compliance for cutting-edge AI products with no established precedents

Pierre-Paul: Generative AI wasn’t such a paradigm shift for Coveo’s product as the ML infrastructure had already been built along with the data platform. In the end, it’s a cloud application. Nevertheless, security and compliance were an intricate part of the go-to-market strategy.

When we say GRC can be seen as a “product”, we need to remember that security, assurance and, in AI’s case, grounding, need to be sold too, both internally and externally. We even leveraged a company-wide prompt injection “hackathon” as a form of assurance in the effectiveness of the generative answering service. Our cloud advisors team and Offensive security team stepped up too. It was an all-company effort.

GRC Engineering: Theory vs Practice

What's actually working versus theoretical when implementing GRC engineering?

Pierre-Paul: One of the lessons I’ve learned is that I refuse to compromise on communication excellence in a GRC team, even if it means less technical depth. No matter how skilled our GRC and DevSecOps teams are, we can’t be everywhere, changing everything for each DevOps team.

What we do instead is request changes (to authentication, coding, AppSec, or cloud platforms) and every one of those requests requires direct developer intervention. Over time, developers get exhausted, and our “capital” with them declines.

After all, no engineering manager is evaluated on risk reduction, so accountability for security is often theoretical. Without strong customer demand, many DevOps teams would not engage with these issues, despite vocal support from senior engineering leadership and the CTO.

On the GRC side, we face our own balancing act. We must remain lean, but often tell ourselves: if we don’t do it, no one will. Meanwhile, we’re buried under poor questionnaire automation tools, outdated Word forms, and customers clinging to on-premise requirements that cloud vendors cannot realistically meet.

Add to this legacy apps, bad historical decisions, and compliance theatre driven by inflexible customer demands, and the result feels like a constant tug-of-war between past and future.

That’s all for the first deep-dive with Pierre-Paul, send him some love!

Let me know what you thought of this format, it’s been super fun to work on! Still iterating so hopefully each entry will be better than the previous one.

A lot of what Pierre-Paul talks about maps to numerous entries in the newsletter so feel free to browse through the archive and check out the previous posts!

If you enjoyed it, you might also enjoy:

• My spicier takes on LinkedIn [/in/ayoubfandi]

• Listening to the GRC Engineer Podcast 

  • Spotify

  • Youtube

  • Apple Podcasts

See you on Thursday!