00 / About Infrastructure · Resilience · Writing

I build resilient technology operations for environments where failure has consequences.

My background spans infrastructure engineering, incident response, enterprise systems, vendor risk, and the practical work of keeping complex environments running. The frameworks and writing here come from that work.

01 / How I think about this work

Close to the operational edge of technology.

I have spent my career close to the operational edge of technology. Infrastructure that cannot casually fail. Systems that have to recover cleanly. Incidents where the next correct decision matters more than the perfect one. Teams carrying enormous responsibility on limited time, budget, and clarity.

The pattern I keep returning to is that most organizations underinvest in the operating layer — the systems, decisions, and frameworks that determine whether a team responds, recovers, and learns, or improvises in the dark. Security tooling gets the budget. Compliance gets the headlines. The operating discipline that makes either of those actually work tends to be the last thing built and the first thing cut.

Frameworks give teams something to argue with. Theory does not.

My work is to make that layer more buildable. Not through more theory, and not through another vendor stack, but through frameworks and operating models that hold up under pressure and give technology teams the language to defend their decisions to the people who fund them.

02 / What I work on

Four areas of focus.

Domain A.01

Incident response and security operations

01Governance
02Architecture
03Technology
04Culture

The framework I'm most known for — Incident Response 2.0 — moves organizations from reactive firefighting to measured, insurable resilience. It rests on four pillars and a clear operating loop. The work is making incident response something a team can prove, not just perform.

IR 2.0 · Sense → Decide → Act → Learn
Domain A.02

Infrastructure resilience

The systems, architectures, and operating practices that keep technology environments running through outages, vendor failures, and the messy edge cases that don't show up in best-practice diagrams.

Data centers · Networking · Identity · Virtualization
Domain A.03

Practical frameworks

IR 2.0 is one. The Cognitive Firewall — a practical model for filtering noise and preserving clarity in an overloaded information environment — is another. Both come from the same conviction: complex problems are easier to solve when there's a structure that can be taught, drilled, measured, and improved.

IR 2.0 · Cognitive Firewall · Calm Loop
Domain A.04

Writing and speaking

Essays on resilience, vendor accountability, and the human side of operating complex systems. Talks at industry conferences when the topic warrants it.

GRC Outlook · InfoSec World · Long-form
03 / Where the perspective comes from

Built inside the work, not in spite of it.

The frameworks and writing on this site come out of that work, not in spite of it. IR 2.0 was developed inside an environment where incident response actually had to function, presented at InfoSec World 2025, and published in GRC Outlook as The Insurability Imperative: Why Incident Response 2.0 Is No Longer Optional. The Cognitive Firewall came out of trying to stay clear-headed and present in a media environment optimized to extract attention. Both are built from things I have actually had to figure out, not things I read about.

Earlier work spans incident response coordination, infrastructure engineering across enterprise environments, and consulting services leadership. The pattern across all of it has been the same: complex environments, high stakes, real consequences when things go wrong.

Now Founder
Deretti Cyber Labs
Applied research · Home of IR 2.0
An applied research initiative focused on security-by-default resilience and the home of the IR 2.0 framework.
Now Day Role
Head of Infrastructure & Engineering
Global eDiscovery firm
Oversee globally distributed enterprise systems supporting some of the most demanding legal and investigative workflows in the industry.
Earlier Field Work
Infrastructure & Incident Response
Enterprise environments · Consulting
Incident response coordination, infrastructure engineering across complex enterprise environments, and consulting services leadership. The pattern across all of it has been the same: complex environments, high stakes, real consequences when things go wrong.
2025 Output
Insurability Imperative
InfoSec World · GRC Outlook
IR 2.0 was developed inside an environment where incident response actually had to function, presented at InfoSec World 2025, and published in GRC Outlook.
04 / Working principles

Four principles, drawn from the work.

Principle / 01

Tools are not the operating model.

Security tools matter, but teams still need decision paths, recovery practice, evidence discipline, and communication habits. Those are the parts that have to be built.

Principle / 02

Frameworks should be tested against reality.

A good framework gives teams something to adapt, challenge, and improve. The ones that survive that process earn their place. The ones that don't were never going to help anyway.

Principle / 03

Operators should be part of the conversation.

The best plans are written close to the people who have to make them work. Distance from the operating reality shows up later, usually at the worst possible moment.

Principle / 04

Human load is part of system design.

Incidents are technical events, but they are carried by people. Culture, fatigue, attention, and clarity are first-order variables, not soft considerations.

For speaking, advisory, or research inquiries, get in touch.