NexLINKEDIN ARCHIVE / Security
Security capability needs an operating model
Something I’ve been reflecting on lately is how often Cybersecurity conversations start with technology, when the harder problem is usually what happens after the technology is in place.
By Phil Kinsley
Adapted and republished on Nexlinks. The publication date is the original article date; the text is preserved as historical author commentary.
Date derived from the original LinkedIn post identifier, shown in America/New_York time; the export supplied only a relative age.
Historical author commentary. Statements and links reflect the original period; this import is not a new factual verification of every historical claim.
Something I’ve been reflecting on lately is how often Cybersecurity conversations start with technology, when the harder problem is usually what happens after the technology is in place.
In a lot of the conversations I’m having, the capability is already there. MicrosoftDefender, Sentinel, Entra, Purview, Intune, third-party platforms, managed services. The challenge is not always what has been bought or deployed. It is whether there is clear ownership around keeping it effective.
Who is reviewing the configuration six months later? Who is tuning detections as the environment changes? Who is looking at new MicrosoftSecurity capabilities and deciding whether they should be adopted? Who is making sure policies still reflect how the business actually operates?
I think that is where security programs can quietly lose value over time. This is not because the technology failed, but because operational ownership became less clear once the implementation work was complete.
That has probably changed the way I think about SecurityMaturity more than anything else recently.
Original publication
Original LinkedIn post ↗Original writing supplied by the author. Feed cards, repeated article announcements, and provider promotion have been removed. Consult current primary documentation before acting on historical technical guidance.