This one is for the Security Engineers. The ones who walk into design review meetings with a list of security controls and walk out wondering why the room went cold.

The meeting you have already had

You walk into a design review meeting with a threat model and a list of controls.

You say, "we need field-level encryption on all PII columns". Engineering says, "That's key management, rotation policies, and rewriting every query across several services that touches those fields."

You tell, "We need mutual TLS between internal services". They say, "These services already run inside a VPC, you want us to manage certificates for internal traffic ?"

They're not wrong. And neither are you.

We talk about defense in depth, least privilege, zero trust and all the other right things. Rarely, do we talk about what each layer costs the team that has to build it, run it, and maintain it.

Every Control has a price tag

Nobody disputes that security matters but every control you recommend is work that lands on somebody's sprint that is already full and could cost engineering teams in many ways.

1. Latency

A policy evaluation, a token validation, a TLS handshake- each one adds milliseconds. Stack a few together, the response time to a user's request that the builder team optimized for months is now noticeably slower.

Users notice, product teams notice more.

2. Infrastructure cost

Audit logging on every API call, at scale that could be millions of log entries per day to ingest, process and store -none of it runs for free.

Controls don't pay the cloud bill themselves

3. Developer time

Input validation on every user-facing field, that could be hundreds of rules, edge cases and more importantly test coverage across many services. That's engineering time not spent on shipping features.

Opportunity cost that does not show up on the Sprint board but product managers feel it every planning cycle.

4. Complexity

Separate VPCs per environment with strict peering rules for network segmentation — right call for blast radius containment, but now the builder team has to maintain complex route tables, VPC peering connections and firewall rules.

A new engineer tries to spin up a dev environment and can't reach a dependency service. To their questions, the answers the builder team has is a one-hour recorded video on network topology , a wiki page that was last edited by someone who is no longer works for the company.

They have a ramp-up problem nobody budgeted for.

5. User experience

Password complexity, minimum of 12 characters, uppercase, lowercase, number and special character — right call for defending against brute force and credential stuffing. But a customer picks something they will remember, gets rejected four times before they can settle on a complex one that sticks, but only to forget it the next week.

This one hits home, we have all been that customer.

The pushback is Healthy

The part we security engineers often get wrong, pushback isn't obstruction, its engineering doing their job. The builder team bears all the costs. Pretending these costs don't exist is how security teams lose credibility.

When a team says "this adds latency", they're telling you something real about their users. When they say "this doubles our infra cost", they're telling you something real about their budget.

Our job is not to override that. Our job is to make the risk visible so the tradeoff is deliberate, and never accidental. The moment we dismiss the cost, we stop being someone the team wants in the room.

And security engineers who aren't in the room don't influence outcomes.

Not Every Path Needs Every Control Layer

This is where you earn trust with engineering teams. Not every workflow carries the same risk, so not every workflow needs the same controls.

A read-only agent serving public data is not the same threat as a write agent touching financial records, so treat them differently. Risk-tier the workflows, and match the controls to the tier, not the other way around.

The fastest way to lose an engineering team is to demand the same controls everywhere.

But then some controls aren't up for discussion, they are not tradeoffs, they are table stakes. Engineering cannot push back on controls mandated by compliance and regulation just because the sprint is full.

The fastest way to lose your customers is to skip controls where they actually matter.

The conversation that works

Instead of "we need this control," you say "here's the risk, here's what mitigation could look like. What does it cost on your end?"

Instead of mandating defense in depth on everything, you ask, "What are we protecting and what's the blast radius if it fails?"

You bring the risk. They bring the cost. The tradeoff is made together.

Lets do this again…..

You walk into the same design review meeting :

Instead of "We need field-level encryption on all PII columns," you say "If this data leaks, here's the blast radius. Field-level encryption is one option. Tokenization is another. What's realistic given your timeline?".

The team engages instead of shutting down. You leave with a plan, both sides win.

But not every meeting ends with a plan.

Sometimes the builder team decides the risk it's not worth the cost, the timeline is too tight, the exposure is low or that the effort to mitigate outweighs the threat.

That's a legitimate outcome, but risk acceptance isn't a handshake in a meeting room full of engineers. The right stakeholders need to be involved, the product owners, the leadership, whoever is responsible to make the decisions.

The reasoning needs to be clear, the decision documented, and the residual risk owned, with a plan and date.

But the work doesn't end with the decision.

Fix the Friction, Not just the Risk

Every difficult design review should teach you something, there is always a takeaway, not just about the system, but about where your organization's security model is creating drag.

Three builder teams pushing back on the same control ? That's a signal to move the controls from services into the platform.

Five teams rolling their own Auth? That's a missing identity layer

Same findings in every security review? Stop reviewing harder. That's your security program telling where the paved road ends.

Secrets scattered across env, vars, config files ? That's a missing standard, not a discipline problem

Teams treating security requirements like surprises? That's not a culture problem. That's requirements showing up too late.

A Security Engineer's job is not an easy one. But the one who goes back and asks, "Why was this conversation hard?", "Why could this control not be implemented on time?" and then finds the answer is the one doing a far more difficult job.

They are ones trying to make the next team's design review shorter, the next control cheaper to adopt and the next trade off easier to make.

Reducing risk in one system is your job. Reducing the cost of security across the organization is your impact.

It is the work that does not show up in a threat model or risk assessment. But it's the work that compounds.

The difference between a security control that starts a hard conversation and one that gets adopted without a push back, isn't just better communication.

It's better engineering, always!

The Bottom Line

Security controls have a cost, Latency, infrastructure, developer time, complexity, user experience. That's real, the builder team knows it even when the security team doesn't say it out loud.

Show up with tradeoffs, not just the checklists. Listen to the push back. Document the decisions, and then go fix the friction that made the conversation hard in the first place, this is the real job.

That's the difference between doing security and building a security culture.

| "Make security easy to adopt. Make risk impossible to ignore." |