About The Cost of Ambiguity
Most security failures don’t start in code. They start when something important goes unsaid: who owns a decision, what a role is allowed to do, which process applies when the deadline is tomorrow. Teams fill those gaps the fastest way they can, and the shortcuts pile up as standing access, shadow AI tools, and technical debt nobody budgeted for.
Eventually someone else reads the result. An auditor, an underwriter, an acquirer’s diligence team. By then it isn’t an engineering problem anymore; it’s a number on a deal sheet.
The Cost of Ambiguity is about that path, from an unstated assumption to a valuation discount, and about how to close it without slowing the business down.
What I write about
Security and valuation. Translating engineering practices like least privilege, secure SDLC, and policy-as-code into the terms boards and investors use: audit results (SOC 2 Type II, ISO/IEC 27001), SEC Item 106 disclosure, and what the company is worth.
Process failures and shadow AI. Why teams adopt unapproved tools and AI workflows (usually an intake problem, not bad intent), and how to build guardrails that don’t cost them their pace.
Evidence over buzzwords. Arguments built on public data such as the Verizon DBIR, IBM’s Cost of a Data Breach report, SEC filings, and academic research, not vendor marketing or compliance checklists.
About me
I’m Elizabeth, a Principal Security Engineer and systems architect.
I grew up in Krung Thep (Bangkok), around a family business. I spent a lot of my childhood in the rooms where business actually happens: banquets, golf games, dinners that ran long. What I learned there is that deals are built on trust and relationships well before anyone signs anything, and that the human side of a business, what people assume, what they never say out loud, decides more than the product does. Building the best mousetrap is rarely enough. I still read security problems that way. The code is usually the last place a failure shows up.
I started building websites in 1998 and ran my own web consulting business through university, which meant negotiating scope, writing contracts, and inheriting other people’s messy codebases long before I ever wrote a security policy. I’ve been in software ever since, and today I work with engineering and support teams across five continents, where the gap between what’s said and what’s assumed gets wider with every language and time zone. These days most of my time goes to secure SDLC, reviewing technical plans before they’re built, and pipeline governance. The areas I focus on:
Identity and access architecture. Zero trust patterns (NIST SP 800-207, CISA ZTMM) and least privilege (NIST SP 800-53 AC-6) for growth-stage systems, with less credential exposure and less audit friction.
Distributed engineering. Secure SDLC controls, contractor boundaries, and data lineage across engineering teams in different countries.
AI governance. Permission boundaries, automated red-teaming, and human review gates for agentic AI.
I hold an MS in Computer Information Systems from Boston University and an undergraduate degree in Political Science (International Relations). My political science work was in quantitative research design, in SPSS and R, and I still approach security the same way: what does the evidence actually say, and where are the boundaries?
Outside of work, I take lessons from dance, cooking, music, and martial arts. More of them carry over to engineering than you’d expect.
Get in touch
The Cost of Ambiguity is free to read. Subscribe to get new essays by email.
For keynotes, panels, or board and investor briefings, see Speaking & Advisory or email elizabeth@thecostofambiguity.com.
