• GRC Engineer
  • Posts
  • πŸŽ™οΈ Beyond The API: GRC Engineering in the Real World w/ Ange Ferrari

πŸŽ™οΈ Beyond The API: GRC Engineering in the Real World w/ Ange Ferrari

From Technical Pentester to Global CISO: Ange Ferrari's GRC Engineering Journey. Deep Dive with a Leader Who's Been There (METRO, AWS, IKEA)

In one of our most comprehensive conversations to date, I had the privilege of speaking with Ange Ferrari, SVP and CISO at Metro, about his fascinating journey from penetration testing to global CISO leadership and his unique perspective on GRC engineering.

Ange's career spans over two decades across diverse industries - from French public sector to Rakuten, Carrefour, AWS, IKEA Group, and now Metro. His perspective on GRC engineering comes from real-world experience implementing programs across different regulatory environments, technology stacks, and business models.

This conversation revealed insights that go far beyond the typical B2B SaaS focused GRC discussions we usually hear.

The Evolution of GRC: From Framework Worship to Pragmatic Engineering πŸ“š

One of the most striking insights from our conversation was Ange's perspective on how GRC has evolved over the past two decades.

The Framework Pendulum

According to Ange, the GRC world has experienced a fascinating pendulum swing:

Phase 1: The Wild West (Pre-2000s)

  • No structured frameworks

  • Highly pragmatic but inconsistent approaches

  • Security professionals working without standardized methodologies

Phase 2: Framework Maximalism (2000s-2010s)

  • Introduction of structured frameworks like ISO 27001, NIST, EBIOS

  • "By the book" implementation became the norm

  • Extremist approach where deviation from standards was seen as failure

Phase 3: Pragmatic Engineering (2010s-Present)

  • Reality check driven by cloud, DevOps, and digital transformation

  • More balanced approach between framework guidance and practical implementation

  • Focus on automation and engineering approaches to scale GRC

The Cloud Revolution's Impact

Ange emphasised how the cloud revolution forced a fundamental rethink of traditional GRC approaches:

❝

"When you think about Kubernetes today and you think about elasticity of your resource. The asset is here, it's not here anymore. What do I do with that? So I think there is definitely a reality check for many organizations that with the speed and the adoption of agile and more DevOps or DevSecec approach, the traditional and the step-wise methodologies or approach is not working."

GRC as Business Enablement: A Leadership Perspective πŸš€

One of the most valuable insights from our conversation was Ange's perspective on how GRC capability directly correlates with career advancement and business impact.

The Business Translation Layer

Ange explained that GRC was his key to transitioning from a technical role to strategic leadership:

❝

"For me, it's definitely a key component to be able to understand what matters for your business. As soon as you start to talk about risk, you switch from the theoretical view that a meteor can fall on the earth versus, what can impact my business tomorrow?"

The Three-Pillar Evolution

Ange's personal GRC journey can be mapped to three key discoveries:

  1. Risk Management Foundation: Understanding that technical controls exist to manage business risk

  2. Governance Structure: Learning how to create organization-wide processes for secure development

  3. Compliance as a Tool: Recognizing compliance as a tool to reduce risk and create structured governance

GRC Engineering: A Simple but Powerful Definition πŸ”§

When asked to define GRC engineering, Ange provided perhaps the most concise definition we've heard:

❝

"For me, how I define it is simply as automation and orchestration of your controls. That's my simple definition of all these things."

The Control-Centric Approach

Ange's perspective centres everything around controls:

  • Risk management = Control-based risk prevention and detection

  • Compliance = Control framework implementation

  • Governance = Control orchestration across the organization

When challenged about the absence of risk in his definition, Ange responded:

❝

"Risk needs to be tied back to control. Because if you are concerned about the risk and you want to be able to prevent that risk to occur or to detect when a risk occurs, what are the controls you put in place in order to achieve that?"

The Reality Check: B2B SaaS vs. Traditional Enterprise 🏭

One of the most eye-opening parts of our conversation was Ange's perspective on how GRC engineering applies differently in traditional enterprise environments compared to the B2B SaaS companies that have dominated the GRC engineering narrative.

The Complexity Multiplier

Ange highlighted three key challenges that traditional enterprises face:

1. Technology Stack Heterogeneity

  • SaaS companies: Homogeneous, API-driven technology stacks

  • Traditional enterprises: "Everything" - all cloud platforms, all software vendors, all types of technology

  • Some vendors have no APIs, others have different API standards

2. Geographic Distribution

  • SaaS companies: Centralized architecture with limited geographic complexity

  • Traditional enterprises: 36 countries, corporate and local solutions, multiple implementations of the same process

3. Legacy System Integration

  • SaaS companies: Modern, API-first architecture

  • Traditional enterprises: Legacy systems, Excel files in shared folders, manual processes

The Standardization vs. Orchestration Balance

Ange provided a nuanced view on how to handle this complexity:

❝

"Standardization and harmonization of your digital landscape is definitely something that all organizations have been working on... But then there is also pragmatism. There are topics where you say, OK, it makes sense to rationalize and harmonize. And there are things you take a conscious choice to not harmonize, not standardize, but then you have to orchestrate."

The AWS Experience: Lessons from the Other Side πŸ”’

Ange's time as Head of Security Assurance for EMEA at AWS provided unique insights into how GRC engineering can work at scale when the technology foundation is right.

The Perfect Storm for GRC Engineering

AWS represented the ideal environment for GRC engineering:

  • Homogeneous technology stack built by engineers

  • Microservices architecture with API-first design

  • Need to demonstrate compliance across hundreds of frameworks

  • Requirement to scale to millions of customers

The Shared Responsibility Revelation

Working at AWS fundamentally changed Ange's perspective on third-party risk management:

❝

"I had already the proper understanding of the shared responsibility model... When I worked for AWS and I had to work with regulators and customers to explain how AWS comply with certain requirements, how AWS cannot comply also with certain requirements because of the shared responsibility model... That's a very different story and that's a very different perspective."

This led to a complete rethink of traditional audit approaches:

❝

"Serving millions of customers, what about 10% of my customers ask for an audit? How I manage that? And... How I authorise the 10% of a million customers to enter in my availability zone to check that I have a power supply in place and mechanisms to avoid power outage or fire detection?"

The Hot Take: Prevention vs. Detection Balance βš–οΈ

When asked for a "hot take," Ange provided what might be the most actionable insight from our entire conversation:

❝

"Find the right balance and think about your balance between prevention and detection. What are the controls that allow me to prevent things to go wrong? What are the controls that allow me to detect when something goes wrong? And don't work on the assumption that everything will be prevented. And don't work on the assumption that you can detect everything."

The Two-Net Strategy

Ange's prevention vs. detection approach can be visualized as overlapping safety nets:

  • Prevention Controls: Stop issues before they occur

  • Detection Controls: Identify when issues have occurred

  • Balanced Approach: Neither net is perfect, but together they provide comprehensive coverage

Key Takeaways for GRC Practitioners πŸ“

1. Maturity-Based Implementation

Don't try to jump from maturity level 1 to 5 overnight. Build your GRC program incrementally, focusing on controls that matter most for your current context.

2. Business-Risk Translation

Use GRC as a bridge between technical security and business impact. This translation capability is key to career advancement and organizational influence.

3. Control-Centric Thinking

Frame all GRC activities around controls - risk identification is a control, compliance verification is a control, governance processes are controls.

4. Environment-Specific Approaches

Recognize that GRC engineering looks different in different environments. B2B SaaS approaches may not directly translate to traditional enterprise environments.

5. Team Diversity

Build teams with both technical and business acumen. Neither alone is sufficient for effective GRC engineering.

Did you enjoy this week's entry?

Login or Subscribe to participate in polls.

That’s all for this week’s issue, folks!

If you enjoyed it, you might also enjoy:

See you next week!

Reply

or to participate.