How to run a security awareness RFP without wasting 6 months

You know that feeling when you take a shortcut to beat traffic, spend 10 minutes on back roads, and somehow still end up right behind the bus you were trying to avoid? All that for nothing.

That’s pretty much how a lot of security awareness RFPs go. Six months of work, a new platform, and 18 months later leadership asks what’s changed. The click and reporting rates are about where they were after the first bump. Often that’s because the process takes over. Switching tools becomes the goal, and somewhere along the way teams lose sight of what they were trying to solve (assuming they were clear on that in the first place).

I lead SoSafe’s presales and bid teams, so I see a lot of these evaluations from the vendor side of the table. Here’s what I’d do differently if I were on yours.

What to work out before you talk to vendors

If we can be real for a second, I think we’re all after the same things: keep the company safe, don’t overpay, cut down on admin, and get a tool people will actually use and like.

You don’t get there by starting with a feature checklist, but by going to the other end and working backwards from what’s actually happening day to day.

Who are you trying to help, and what needs to change for them? 

A factory worker doesn’t learn or work the same way as someone sitting at a desk, and the problem can look completely different from one team to the next. Finance might be dealing with fake vendor requests, while developers could be feeding code into unapproved AI tools.

What can’t you see yet?

Let’s say you know your click rates, but not which team reports suspicious emails more than others. That’s one blind spot you don’t want following you to the next tool. 

What can’t your current tool do?

If you keep having to work around it, that’s usually telling you something’s missing.

What will the board and auditors ask for?

The board might want one thing, while an auditor or regulator could be looking for something completely different.

Who does what?

What can the platform handle for you? Where does your team still need to step in? And what’s going to stay with you either way?

What if staying put is the best move?

Don’t write off your current vendor right out of the gate. Put them through the same checks as everyone else, because you might already have what you need and just not be using it. If not, you know why you’re moving on.

Scoring the right things the right way

I get why RFPs turn into big feature spreadsheets. They’re easy for procurement to score and easy for vendors to answer. But once the spreadsheet starts running the show, it’s easy to get pulled into who has more of what and forget which tool actually solves the problem you came in with.

If the goal is to help people handle real threats better, more features don’t automatically get you there. Take content libraries: thousands of generic modules sound impressive, but I’d care more about which languages the content comes in, whether it feels relevant to the person taking it, and whether people willingly engage.

I’d look at metrics the same way. You can have dashboards everywhere, but if they don’t tell you whether people are making safer calls or where you’re still exposed, they’re not doing much for you.

And don’t take the RFP requirements as given. If something is only there because it was in the last RFP or came from a vendor template, ask what it’s there for before you score it.

Finally, if something barely moves the needle, don’t give it the same weight as something the whole programme depends on.

What the demo won’t show you

The demo won’t tell you how much admin comes bundled with the tool, but a few weeks of actually using it will. A Proof of Value in your own environment lets you find that out sooner, against the directories, user groups, and workflows you already have.

Run through the boring stuff on purpose. How are joiners and leavers handled? How quickly can you change a campaign? If something’s labelled “automated,” don’t stop there. Work through it and see what’s still left for your team to do, because 10 minutes here and 20 there can add up faster than you think. That time is part of the cost too, whether it’s on the invoice or not.

And look at everything that has to happen around the platform too: the SSO setup, API access, directory clean-up, privacy checks, works council reviews, content review, internal comms, and change management. Some things you assumed were standard may sit behind a higher package, or end up costing you more in time than you saved on the licence. 

A demo can make some very manual things look painless, especially regular CSV uploads, which seem simple enough until people start joining, moving teams, and leaving, and someone has to keep the whole thing straight. Compliance reporting can be the same story: if someone still has to export the data and rebuild the report somewhere else, it’s hardly automated. And don’t leave data residency, sub-processors, or security certifications for legal to chase down later.

You want to know what you’re signing up for before you commit, not halfway through implementation.

The experience on the other side

Now put yourself on the receiving end for a minute. You click a simulation. Do you learn something useful, or just feel like you got caught? You report a suspicious email. Do you hear anything back, or does it just end up in a queue? If every time people hear from your department it’s another test, reminder, or a mandatory module, sooner or later they’re going to mentally check out. Try and carry that back into the RFP. It’s harder to put in a box, but it’s what people are actually going to live with, right?

Ask around. People could be using the tool for years, so you want to know what it’s like once everyone’s used to it. Talk to customers who’ve had it for 18 months or so and ask whether people are still engaging, support is still responsive, and what they wish they’d known earlier.

Agree what success looks like before you sign

While you’ve still got the vendor’s attention, agree what success looks like. What are you measuring, what should improve, and how often are you checking? A year or two in, that’s how you’ll know if it’s still doing the job.

If 6 months of RFP work only leaves you knowing which vendor scored highest, you’ve missed half of what it could tell you. Ideally, you should come out of this evaluation process knowing your own programme better too. Hold onto that as you go, and the platform has a much better shot at doing the job you picked it for.

About the author

Harry Jeyarajah
Head of Solution Engineering

Harry Jeyarajah leads the Solution Engineering team at SoSafe, where he helps security leaders back up their awareness investments with solid proof points, covering everything from risk reduction to behavior change. He brings 10 years of experience in the DACH digital landscape, spanning A/B testing, Web and App IT infrastructure, Content Management, and Human Risk Management.

Learn more