ITIL Service Management
ITIL gets a bad reputation in security circles, usually because someone implemented it as a paperwork exercise instead of a way to run IT well. I don't treat it that way. When I bring ITIL practices into an environment, I'm after the parts that actually reduce risk: a change management process that catches a misconfigured firewall rule before it ships, an incident process that routes a security event to the right person in minutes instead of hours, and a configuration management database that tells you, honestly, what's running on your network.
Why this matters for security
Most of the breaches I've reviewed after the fact trace back to a process gap, not a missing tool. An unauthorized change goes out on a Friday afternoon. An asset nobody tracked is still running an end-of-life operating system. A service desk ticket about "slow login" turns out to be the first sign of a credential-stuffing attack, but nobody connects the dots because incident and service management live in separate silos. ITIL, done well, closes those gaps by giving you a disciplined way to manage change, incidents, problems, and assets as one connected system.
How I approach it
I start by looking at what you already do, not what a textbook says you should do. Most organizations have some version of change control and incident handling in place; the question is whether it's consistent, whether security has a seat at the table, and whether the records you keep would actually help you during a real incident or an audit. From there, I help you tighten the processes that matter most — usually change management, incident management, and configuration/asset management — and build the connective tissue between IT operations and the security team so a service disruption and a security event get treated as the same kind of problem when they need to be.
I'm not interested in handing you a 40-page process manual that sits on a shelf. I care about whether your change advisory board actually stops risky changes, whether your CMDB reflects reality, and whether your team can answer "what changed right before this broke" in minutes instead of days. That's the bar.
Who this is for
This work fits organizations that are scaling past ad hoc IT operations, companies that need ITIL-aligned processes to satisfy a customer or compliance requirement, and security teams that are tired of being the last to know when something changes in production.
If your change process and your security program aren't talking to each other, that's worth a conversation. Reach out and tell me where the friction is.