Operating philosophy
How I run a security organization
Four industries, four regulatory environments, four very different threat models — and the same seven positions underneath all of them. These are the things I would tell you in an interview if you asked what I actually believe.
1. Make the risk legible before you try to make it smaller
The instinct in a new security role is to start fixing. It is the wrong first move. Until exposure is expressed in terms the business can evaluate — ideally in dollars, tied to specific business processes — every remediation decision is being made on intuition, and every funding conversation is a negotiation between people who are describing different things.
A quantified risk model is not a reporting artifact. It is the instrument you steer with. It tells you what to do first, it tells you what a proposed investment is worth, and it is the only way to prove later that you reduced cost without increasing exposure. Build it early, make the assumptions explicit, and let people argue with it.
2. Sequence by business impact, not by severity score
CVSS describes the properties of a flaw. It knows nothing about which systems run your plants, hold your regulated data, or would stop a shipment. Working the queue in severity order is defensible, auditable, and quietly misallocates most of your remediation capacity.
The right question is not “what is the most severe finding?” but “which unit of effort removes the most exposure?” Those queues look very different. The second one includes a lot of unglamorous segmentation and access work, and it consciously defers some high-rated findings — which you can only defend if you can show the math on what you did instead.
3. Buy the control, not the logo
Security portfolios are organized by vendor and budget line; security value is delivered by control. Because of that mismatch, nearly every mature portfolio carries substantial redundancy that nobody can see, alongside controls with nothing real behind them because a product with an adjacent name is in the stack and everyone assumed it was covered.
Re-cut the portfolio against the control environment at least annually. Map every tool to the specific controls it delivers, at what coverage, for which assets. The overlap becomes obvious and, more importantly, arguable. So do the gaps.
4. Governance has users, and if it isn’t usable it isn’t real
A policy set written to be quoted in audit responses will be quoted in audit responses and followed by nobody. Governance is a product with users — engineers, plant operations, procurement, application owners — and the test of it is whether those people can do the right thing without asking you.
Practically: one control environment, cross-mapped to whichever frameworks your audiences care about, rather than parallel programs per audience. Evidence generated by operating the program rather than assembled in a scramble before an assessment. Exceptions with named owners and expiry dates. That is what converts a program that passes one audit into a program that stays passable.
5. Outsource volume, never the judgment layer
Managed services are the right answer to high-volume, well-specified, procedure-driven work. They are the wrong answer to anything requiring knowledge of what your systems are for.
The question to ask about any managed security service is not what it costs but what capability you will no longer have in two years. If the provider is writing your detection content, they are accumulating your environmental knowledge and you are renting a security program rather than running one. Keep detection engineering, escalation, and incident response in-house — it keeps your team developing, keeps the relationship replaceable, and means someone internal can actually take command when it matters.
6. Build for the organization that stays
A program that depends on one person’s knowledge, relationships, or heroics is not a program. It is a liability with good intentions. The measure of security leadership is what still works eighteen months after you leave.
That means documented ownership, defined operating models, KPIs and SLAs that someone else could run the program against, and deliberate investment in the people below you. It also means resisting the satisfaction of being the indispensable person in the room, which is a genuinely hard habit to break.
7. A security program you cannot fund is a hobby
Security work happens at the speed the business is willing to pay for and adopt. That makes translation — from technical risk into business decision — a core competency of the role rather than a soft skill adjacent to it.
An executive team cannot act on a finding count. They can act on an exposure figure, a cost to remove it, and a sequence. A first-generation security function that positions itself as the department of no gets routed around within a year and defunded within two. Being useful to the operating business is not a compromise of the security mission; it is the only delivery mechanism it has.
The one-line version
Quantify the risk honestly, spend your capacity where it removes the most exposure, keep the judgment in-house, and report it in language that produces a decision rather than a status color.
Where this came from
These positions were formed across four industries: seven years assessing IT and cybersecurity for 500+ banks and credit unions, building the first security function at a $6.5B retailer, running a 100-person security organization at an academic medical center, and building enterprise governance from nothing at a $14B global manufacturer under an IPO timeline.
The case studies show them applied to specific problems.