You're About to Sign Security Settings Nobody Reviewed.

During a proof of value, vendors almost always find something alarming. Finding something is not proof the tool will protect your business better than another product. It often reveals the assumptions and default decisions you’re about to inherit if you buy the product.

What the Board Actually Wants to Know Before You Sign

The board is not asking whether the tool works. They are asking who signed off on how it is configured, and whether anyone checked.

That question comes up in almost every version of this meeting, a board review, a CFO sign off, or the person who inherits your role in a few years. They all end up asking why this vendor got chosen.

They are weighing whether you can answer one thing cleanly: did your company choose this configuration, or did you accept whatever shipped in the box. A demo that looked strong during the sales cycle does not hold up under that question. Neither does “the vendor’s team recommended it.” What holds up is a record of what you asked, what you checked, and what you decided on purpose instead of by default.

The weak answer sounds like this: “the vendor walked us through it and it seemed solid.” That sentence has no owner in it. Nobody on your side decided anything, the vendor did.

The strong answer sounds like this: “we asked what the default configuration was and who at the vendor decided it. We asked what their proof of value actually proved when it found something in our environment. And we confirmed a person reviews any new automated rule before it blocks real traffic.” That answer has an owner in every sentence. It closely reflects what Tony Lauro, Akamai’s Senior Director of Security Technology and Strategy, laid out on a recent episode of Signed: “AI Agents Read Your Site in Under 1,000 Tokens. Most of What You Built Never Gets Seen.”, describing exactly what separates a reviewed purchase from an accepted one.

Why Vendors Set Defaults the Way They Do

Defaults exist for a reason, just not necessarily yours. A vendor sets the default for fast onboarding, a low support ticket count, broad compatibility, and a demo that goes smoothly. Those are good priorities for the vendor. They are not automatically good priorities for your company, and nobody tells you that at signing.

Defaults also get more expensive the longer they sit unreviewed. The most costly configuration is rarely the wrong one. It is the one that quietly becomes permanent because nobody wants to touch it once it is running in production. Every default you accept today becomes the baseline every future change gets measured against.

What a Proof of Value Actually Proves

That same pattern shows up in what a proof of value actually finds. Large environments almost always contain a few things: a dormant account, a forgotten system, an unusual traffic pattern, an exposed service.

A vendor does not need a better product to find one of these. They only need enough visibility to look. Many competent products would surface a similar list. The real question is what happens after something is found, not whether it was found at all.

Build a Decision Record That Answers These Five Questions

• What is the default configuration, who at the vendor decided it, and which of those defaults did you choose to keep. If nobody can answer that in one sentence, the default was an accident, not a decision.
• What did the vendor’s proof of value actually find, and what did you ask about it. The finding is not proof the tool works. It is proof your environment has debt like every other one.
• Does a person review a new automated rule before it blocks real traffic, or does it deploy on its own. A rule with no oversight eventually blocks good traffic too, and nobody notices until a customer complains.
• Who owns the tradeoff between blocking attackers and losing customers, and does that person ever talk to whoever owns your brand and your marketing. If security and brand safety sit in separate meetings, the tradeoff already got made, just not by anyone in the room.
• If the product includes any AI features, those defaults deserve their own review, separate from the rest of the platform. AI carries a different set of assumptions: what happens to a prompt going in, and what happens to the output coming out. Most tools built for the old web were never designed to watch either direction.

The Questions You Will Get Asked in the Room

• Who else did you look at, and why did they lose. A strong answer names the alternatives and the specific reason each one lost, not just “this one felt right.”
• What does it cost you if this is wrong. A strong answer has a number or a timeline attached, not a shrug.
• Who signed off on the configuration you are running today. A strong answer names a person and a date. If the honest answer is nobody, that is the finding, not something to explain away.
• What happens the day the vendor changes something. A strong answer describes a real notification and review process on your side, not “we will find out when something breaks.”
• Which of these settings are still the demo configuration, and which ones actually run in production. Most buyers never ask this, and the two are rarely identical.

What Changes When Someone Checks the Defaults First

Most teams build this record after the fact, once someone in the room asks the question nobody prepared for. The teams that walk in with it already built had someone challenging the vendor’s assumptions from the start.

If you’re evaluating a vendor right now, build this record before you discuss pricing or sign anything. This is where to start.

Every major technology purchase eventually becomes someone else’s responsibility. The goal is not to remember why the vendor recommended those defaults. It is to leave behind a record showing why your company accepted them.

We’ll tell you if this deal is actually competitive. Get Started.

No pitch. No prep. Just answers.