Every security leader eventually inherits the same sentence: "We need a SOC." Sometimes it comes from a board still rattled by a near-miss. Sometimes it's a compliance deadline. Either way, you have ninety days, a thin budget, and a watching audience. Here is the sequence I run, refined across four build-outs, that gets you to defensible operations without lighting money on fire.
The instinct is to buy a SIEM. Resist it. You cannot defend what you cannot see, and you cannot see what you have not inventoried. The first month is asset discovery, log-source mapping, and an honest data-flow diagram. I would rather have clean telemetry from twenty critical systems than noisy firehoses from two hundred.
Pick your crown jewels first, identity, endpoints, and the systems that would end up in a breach notification, and instrument those completely before widening the net.
A SOC is not a room full of screens. It is a decision-making function. Build the decisions first.
Do not write forty playbooks. Write one, for the alert type you will see most, and actually run it end to end, including the awkward handoffs. The gaps you find in that single rehearsal are worth more than a binder of theoretical procedures.
By the end of the quarter you want a closed loop you can show the board: an alert fired, a human triaged it against a defined process, an action was taken, and the detection was tuned afterward. That loop, small but real, is the seed of everything that comes next. Maturity is just that loop, repeated and widened.
The mistake I see most often is leaders trying to launch fully formed. You do not need fully formed. You need true, one honest, working loop, and then the discipline to grow it.
`, "_default": `This is placeholder body copy so you can see how a full Field Note reads on the page, typography, rhythm, and spacing are all production-ready. Replace it with your own writing and the layout will hold.
Security leadership lives in the gap between what the tooling promises and what the team can actually operate. My writing tends to live in that gap too: less about the newest product category, more about the operating decisions that determine whether a program is resilient or merely busy.
Tools don't defend organizations. Teams running good processes against good telemetry do.
Whether the topic is MDR selection, detection engineering, or governance, the underlying question is the same, how do you turn finite attention into reliable defense? That is the thread through everything here.
Swap this copy for the real article. The container, the measure, and the type scale are all set up to make long-form reading comfortable.
`, }; /* ---------- ABOUT ---------- */ function AboutPage({ go }) { useScrollTop("about"); return (About
I'm {SITE.name}, an information security leader who builds, matures, and operates cyber defense programs across managed services, the enterprise, and major-event environments. Above all, I excel at building, training, and operationalizing the security teams that run them.
The short story
I've built and run cyber defense from nearly every seat, leading a 50-person managed security organization, standing up the security operations behind the NFL's biggest events, and directing the talent and governance programs that make delivery repeatable. That range is the point: I've done the work I now ask of teams.
My core strength is building and operationalizing security teams, recruiting, training, and developing people, then wiring them into the delivery models, processes, and tooling that scale without breaking. I've designed services able to double a client base with no loss of quality, and cut operating cost while protecting growth.
I lead security as a business function: translating technical risk into executive priorities, service economics, and board-ready reporting. I'm equally at home running an incident, standing up a SOC, building an MSSP offering, or briefing the C-suite, and I treat governance (SOC 2 Type II, NIST, ISO/IEC 27001) as something to wire into delivery, not bolt on after.
I write the Field Notes on this site to share what actually works on the operations floor, the frameworks, the post-mortems, and the unglamorous lessons that don't make it into vendor decks.
{f.d}
Field Notes
I'm putting together field-tested writing on building and operationalizing security teams, running operations, and leading through incidents. Check back shortly.
{a.dek}
Contact
Advisory work, speaking, a hard problem in your SOC, or just a good security conversation. My inbox is open.