I just joined Lovable as a GRC Engineer.

If you don't know Lovable, it’s one of the fastest-growing software company in history, empowering the 99% to build: you describe what you want to build, and it builds it.

I hope to do the best work of my life there and help chart what the future of GRC is at the edge at an AI-native rocketship 🙂 

After working for 4+ years at GitLab, I hadn’t onboarded into a new GRC program for a long time :) But week one reminded me of something I keep relearning: the build doesn't wait, and neither does the work of understanding what you're building into. You need to get both right to thrive in today’s high velocity environment.

Here are five things I focus on.

By the way, nothing changes for the newsletter, you’ll still get weekly blog posts from your truly, hopefully just as valuable as the content has been in the past 🙂 

IN PARTNERSHIP WITH

Webinar: Applying GRC Engineering to 3rd Party Risk Management

Your vendors are an extension of your environment, yet most third-party risk programmes treat them separately, with generic questionnaires and periodic reviews that are more compliance theatre than risk management. Join Tomer Roizman (CTO, Lema AI) and me for an open discussion on engineering third-party risk as first-party risk.

Understand velocity before you touch anything

The first thing you need to understand about a new company isn't their tech stack or their compliance posture. It's how fast they move.

But velocity isn't just deployment frequency. It's also how risk is thought about. Is risk a quarterly meeting? A Slack thread? An informal conversation before a decision gets made? That's your real approval workflow, and it matters more than whatever the policy document says.

Lovable moves fast. That's not a problem, it's a design constraint. Every decision I make has to pass one test: does this work at this speed, or does it assume a pace we don't have?

If you build a programme sized for a slower company, you become either a blocker or irrelevant.

Know your north star before you optimise for anything else

Every company has a compliance north star: the thing that, if you miss it, causes immediate, concrete damage.

For some that's a certification in motion: a SOC 2 Type II observation period already running, an ISO 27001 audit scheduled, getting through the FedRAMP 20x Moderate pipeline, etc.. For others it's a contractual commitment baked into enterprise deals, or a regulatory deadline.

Ask on day two. Not day thirty. The thing that makes you look most incompetent in a new role isn't moving slowly on a new initiative. It's missing an obligation that was already in motion when you arrived.

Get the list. Own it. Keep it visible.

Map the stakeholder landscape before you need it

Stakeholder mapping isn't just "who are the important people." It's "what is this company optimised for, and who does that make important."

There are a few archetypes worth knowing:

• Engineering-driven: Velocity is sacred. Your risk is becoming a blocker. Frame everything as "how does this make engineers faster or safer."

• Product-driven: Optimised for shipping. Risk conversations need to connect to what breaks the roadmap.

• Compliance-driven: GRC is already in the culture. Overindexing on speed is your risk here, not the other way around.

• Research-driven: IP, data, and access come first. Stakeholders often don't think in compliance terms at all.

Get the archetype wrong and you build credibility with the people who don't unlock the programme, and miss the ones who do.

The historical tensions won't show up in your onboarding pack. Pay attention to the careful word about a past audit process, the slight hesitation when you ask about a particular team. Collect that context early.

Build your system baseline before you build your risk register

Most GRC programmes start with a risk assessment. That's the wrong order.

Before you can assess risk, you need to know what exists: infrastructure provider, CI/CD pipeline, databases (managed or homegrown, access, object vs. relational vs. noSQL, etc.), languages, and any internal tools built by someone who left two years ago that nobody fully understands.

In a small or fast-moving company, you may not inherit a formal risk register or a current threat model. Your job is to build the first version. Not the perfect one.

Start with the 10-15 systems that matter most and answer three questions for each:

1. What's the blast radius if this is compromised or goes down?

2. Who has access, and is that list current?

3. Where does data from this system go?

That gives you a working map you can refine as you go.

Act on what you know. Hold the big decisions until you know more.

The instinct in a new role is to spend 90 days listening before doing anything. I understand it. I don't fully agree with it.

Quick wins build credibility and earn you the relationship capital to make harder asks later: a documentation gap fixed, a vendor assessment completed, an access review that was overdue.

But quick wins can also be a trap. If you optimise entirely for visible output early, you lock in decisions that are hard to reverse. You patch symptoms before you understand the disease.

The balance: act on what you already know, hold the larger structural decisions until you have more context. And think about the smallest version of the long-term project you can start now. You can't build a full vulnerability management programme in month one, but you can stand up basic scanning, make the output visible, and start the conversation about triage. That's the seed. It delivers value now and builds toward the scale you'll need later.

I came into this role with a theory about what the programme needs. That theory will be wrong in some places. But having a theory from day one, even a provisional one, means I'm asking sharper questions and building toward something rather than reacting.

Hold your theory loosely. But have one.

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

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 next week!