Redline volume tracks control maturity

Last quarter at Decagon, redline volume on enterprise deals dropped. Legal didn’t get easier to work with. My team had finally shipped controls that had been showing up in negotiation for months.

Before a deal closes, customer counsel marks up your terms — retention, model use, audit rights, liability — and someone on your side pushes back. Most teams file that under overhead. I use it to see where the program actually is.

On the deals I touch — mostly $500K–$8M ACV, F500 and large mid-market — the number and shape of security redlines tells me more about control maturity than most internal dashboards. Strong programs don’t redline more. They redline less, because there’s less gap between what the contract says and what you can show.

Aggressive redlining isn’t always strength

People read pushback in negotiation as a sign the security team is doing its job. Sometimes it is. Often the pattern runs the other way.

When controls are in place and evidenced, contract language matches reality. Security touches fewer clauses, cycles get shorter, the same questions stop coming back. When controls are still on the roadmap — or owned by three teams with no shared evidence — redlines spread. Every gap turns into a negotiation because nobody can point to how the requirement is met.

What to track

A spreadsheet at deal close is enough to start.

Dimension	What it tells you	Healthy trend
Volume	How many clauses security touches per deal	Flat or down as controls land
Recurrence	Same topic on every deal (retention, subprocessors, on-prem boundaries)	Topics drop off after implementation
Classification tier	Must-have vs. prefer vs. acceptable vs. cosmetic	Must-have bucket stable or shrinking
Time-to-resolution	Cycles from first redline to agreed language	Shorter as evidence improves

On one eight-figure deal, subprocessor redlines went from eleven clauses to two after I shipped a customer-facing change-log tied to production controls. Same buyer. Better evidence.

I bucket clauses as must-have (walk away if unresolved), strongly prefer (escalate internally), acceptable with compensating controls (write down the compensating control), and cosmetic (don’t burn senior time). If must-haves grow quarter over quarter, the program isn’t converging.

Redline what you’re building

Push hardest on clauses tied to controls you’re actively building. At Decagon, when we’re implementing zero-day retention, model isolation, or PII redaction in the inference path, I hold the line on those terms until the control ships and we can collect evidence. After it’s in production, I stop fighting the same language.

Your playbook should get simpler over time. If it doesn’t, either product is outrunning security, or you’re redlining by habit.

Buyers now ask for things that barely existed in frameworks eighteen months ago — zero-day retention, no training on customer data, supervisor models, red-team evidence, PII redaction timing. Heavy redlining there usually means the program is still catching up, not that the function is weak.

When you lose a redline

When legal accepts language I can’t support with a control, I’ve either found a control I need to build, or found language that didn’t matter. Both are useful.

I review redline themes quarterly against control ship dates. Deals that only live in a folder don’t help the next one.

Plot volume and category against when controls landed. Flat or falling redlines while controls improve is a good sign. Redlines growing with headcount usually means you’re adding activity, not assurance.