I Reviewed 500+ fwd:cloudsec Submissions, These Are My Key Takeaways

UPDATE 2025-05-05: This post has now been updated in light of experiences reviewing for fwd:cloudsec North America 2024 and 2025, and fwd:cloudsec Europe 2024, to better support those planning to submit to fwd:cloudsec Europe 2025.

As a reviewer for both fwd:cloudsec events, I get to see a wide range of conference submissions every year. There are usually several common themes in reasons why I scored a submission the way I did. I reckon other reviewers were scoring similarly, given the discussions I’ve taken part in. I thought I’d share some of my observations here. This is all particularly relevant to fwd:cloudsec EU, given I’m leading the CfP there. That said, I’m sure a lot of it will generalise to other cybersecurity cons too.

The Positives

Many submissions were a delight, and made it simple for the committee to select them for the final slate. Most of the talks that were easy acceptance decisions ticked some, if not most, of the following boxes:

A well thought out and detailed submission that makes it clear what they wanted to talk about
Allowed the committee to assess the speaker’s credibility for the submitted topic. Reviews were initially done blind, so we based this on the submission detail, not who the speaker was.
An explanation of why their content would be useful and relevant to our attendees
Novel content, and an explanation of how their work fit into prior art and the broader industry
An obvious connection between the content and the conference’s core themes
A demonstration that they were talking from real world experience
- For fwd:cloudsec in particular, if you can demonstrate real-world engineering experience in a complex organisation encountering interesting challenges, that’s likely to make you stand out from the crowd.
- For fwd:cloudsec Europe, there’s a particular benefit to being able to contextualise your work within the various EU regulatory frameworks (DORA, NIS2, the AI Act, GDPR etc)
Detail on how they’d spend the time, especially if they’d requested one of the longer session types

What Counted Against a Submission

There were similarities among submissions we turned down, too. I’ve included the most common and important ones below.

Low Effort/No Detail

It was depressingly common to see people submit a few, very high level lines of text in the abstract. As a reviewer, this leaves me with four problems:

There’s not enough detail to know what you want to talk about, and whether that’s a good fit for the event.
I can’t tell if you know what you’re talking about.
I don’t know if the content is at a level that is appropriate for our experienced audience.
If what you present is as low effort as your submission, it’s not likely to be high quality.

It makes our lives easier if we’ve got plenty of detail to work with. It also shows you cared enough about speaking at our event to put some time and effort into the submission. That goes a long way towards convincing a review board you’re worth having as a speaker!

There’s a common sub-problem here, which is speakers thinking they can get away with lower effort submissions by relying on their reputation (or the reputation of their firm) to get them through the door. This will often backfire - while conferences often like to have big names on the schedule to attract more attendees, many conferences run their review process “blind” (without reviewers seeing the names or bios of speakers) to reduce bias and ensure fairness. Such submissions frequently get filtered out early on as a result.

Smells Like a Sales Pitch

Many organisations have a vested financial interest in their staff speaking at events. This is often for brand building and showing off what they’re capable of to potential buyers. This is fine, and well understood by reviewers. What no one wants, at a practitioner-focused event, is sales pitches.

Submissions are usually scrutinised for indications a vendor might be pitching their products or services. This can be a fine line to walk as a submitter, especially if your company is paying for the trip. If part of your talk talks about solving a problem by paying for your company’s offerings, it’s a vendor pitch. fwd:cloudsec and other community focused conferences are the wrong place for it. It’d fit better at events with paid talk slots, like RSA, Infosec Europe in the UK, V2 Security in Denmark and so on.

It’s easy for talks to get caught in the crossfire here, unfortunately. If the reviewers think a submission might be a sales pitch, they’ll probably reject it to avoid the risk. Some tips to avoid that:

If you’re talking about tools you want to show off, make it clear that they’re free/OSS if they are
Be very clear to differentiate your products and services from what you’re submitting.
- If your company focuses on the space you’re presenting on, you should acknowledge that. You should then make it clear how this submission won’t be a sales pitch for their products. You could explain how the submission is going to be product-agnostic, or how it’ll discuss a range of different approaches.
Avoid mentioning the company name all over the submission.
- The company name is relevant if you want to present how you solved a particular challenge. As a vendor, mentioning it can make the submission sound more vendor pitch-y.

No New Content

At high-end or specialist conferences, existing content is less desirable than something new. Be clear how this will differ from prior work, if you’ve delivered the talk elsewhere.

We also had a few submissions this year that were looking to present the contents of a blog post. Personally, if I can go read a blog post covering the submission, I don’t see why we’d spend a talk slot to listen to it. I’d rather make space for something new. This isn’t a universally held view, but I’m not the only one who raised this on the committee. Given that, it’s worth explaining how you plan to build or expand on the blog post in situations like that.

Doesn’t Fit the Conference Theme

Many conferences have specific themes or topics they focus on. In the case of fwd:cloudsec, it’s public cloud infrastructure security. Some content will cover related topics too, such as cloud native/Kubernetes, SaaS, cloud-based identity systems and so on. Expect talks to be rejected if you can’t show relevance to their core themes. It’s sadly common for us to see submissions on whatever the current hype topic in the industry is - AI/LLM security right now, for instance - where there’s no clear link between the submission content and cloud security.

Inappropriate for the Audience

Reviewers are looking for content that’s appropriate for the conference’s audience. Entry level content isn’t likely to get accepted at a specialist conference. It’s a waste of the audience’s time, if they’re already experienced. Equally, most of the audience won’t follow niche content at a more generalist con. Target your submissions to events appropriate for what you have to say.

Hard to Tell What You’ll Do With The Slot

Reviewers want the accepted talks to provide value to their attendees. To me, that means I’m looking for a few things:

What will the speaker spend the time we’re giving them on?
- Will they focus on the things we think will be interesting? Or is it going to meander through the less interesting portions to get there?
What will attendees learn from this that they can take away with them?
- Talks should be informative and useful to the listeners. This means actionable, real-world outcomes or advice.
- These days, few people want to see some infosec rockstar rock up to just drop vulnerabilities.

I will likely score your submission lower if I can’t see how you’ll spend the time. This is especially true if you’ve asked for a longer talk slot!

Presenting a Tool

The jury’s definitely still out there on this one. There are specific tool tracks (like Black Hat Arsenal) where it’s appropriate to present on a tool. Personally, I have no desire to see a talk of someone presenting a tool and its feature set outside of that. Presenting a problem, approaches to solving it, and then demoing a tool that you’ve built as part of that work? Great. 20 minutes of “here’s a tool, and here’s all the different tricks it can do”? I’d rather go read your README.md. It doesn’t give the audience much to take away, other than the specifics of your tool. That’s not the kind of learning most people will tune into a conference talk for.

In Summary

There are many ways to write a conference submission, and I love the diversity in approaches that we see. That said, if you want to succeed, you should ensure that your submission:

Provides plenty of detail on the following:
- What you want to say and why.
- How it fits into the broader picture.
- Why it would be interesting to the conference’s audience.
Demonstrates your expertise on the subject matter
Shows how you intend to use the time you’re given
Doesn’t sound like a vendor pitch