The security requirement that almost blocked a go-live, and how it was solved in a week

A bank in Peru, with a very low risk appetite, demanded a custom tokenization layer to replace the standard VPN — something the product didn't support yet, weeks before its go-live. Escalating the requirement immediately as a P1 blocker, instead of leaving it as "mentioned in several sessions", got it delivered in under a week and protected the pilot's expansion from 20 to 200 users — roughly $20,000 USD in monthly recurring revenue.

The requirement everyone knew about and nobody had escalated

The requirement had already been mentioned several times in sessions with the client. The problem wasn't that nobody knew — it was that nobody had formally escalated it as what it actually was: a go-live blocker, not a technical preference.

What do you lose by not escalating a security requirement in time?

According to the IBM Systems Sciences Institute, fixing a defect or security requirement after launch can cost between 60 and 100 times more than resolving it in the design phase. That same principle applies to requirements that are known but not prioritized: the later they're addressed, the closer they are to becoming the reason a strategic client never reaches production.

How do you ask a product team to reorder its priority this week?

I escalated it immediately to the product team as P1, explicitly as a blocking requirement and not a nice-to-have, and helped translate the client's risk concern into clear technical acceptance criteria. We set time expectations, requested temporary reprioritization, and held brief daily check-ins to track progress and keep the client informed.

What gets protected when you do prioritize in time?

The team delivered the tokenization layer in under a week, validated in a non-production environment before go-live. That let the client expand its pilot from 20 to 200 users the following month — close to $20,000 USD in monthly recurring revenue protected, and at least a month of adoption that would otherwise have been lost, with the churn risk that implies on a strategic account.

The lesson I take

A security requirement mentioned several times without being formally escalated isn't a solved problem — it's a risk that keeps growing in silence. The difference between a mention in a session and a P1 blocker is, many times, the difference between protecting an account or losing it.

Data sources: IBM Systems Sciences Institute — relative cost of defect correction by development lifecycle phase (60–100x in production vs. design).

Frequently asked questions

How do you prioritize a blocking security requirement against the product roadmap? By formally escalating it as a P1 blocker the moment it's identified, not as a session mention, and translating the client's risk concern into concrete technical acceptance criteria.

Why does fixing a security requirement late cost more? Because the later the development lifecycle phase, the more components depend on the original decision. Fixing in production can cost between 60 and 100 times more than resolving it in design (IBM Systems Sciences Institute).