I'll admit something up front: when I think about security, I start with risk. Intellectually, it's the obvious starting point. But I've sat in enough customer meetings to know that what's logical isn't always how decisions get made. So I sat down with my colleague Kevin Cheeley, who leads our Integrated Risk Management (IRM) work at CoreX, and asked him every uncomfortable question I could think of.
Who owns risk? Where does the CISO actually fit? And is all of this just too much to take on? Here's what I took away.
My opening question was a version of the chicken-and-egg problem. Kevin answered that neither came first. They've always been there together. A risk is simply a potential bad thing that could happen to the organization, and threats and vulnerabilities are two of its main categories. Security and risk look at the same exposure from different angles. They're completely intermingled.
That changes the conversation. If risk and security are one problem, a risk program run by two people in a corner and a security program run by a scanner team in another corner are both incomplete.
I played the risk professional and asked Kevin directly: if I flag shadow AI as a top risk for 2027, then what? Do I ask for funding? Hand it to the CIO? Hand it to the AI lead? Kevin's answer gave me a clear model of who does what:
The risk manager is a facilitator, not the fixer. Think of them as the project manager of risk. They frame risks against an industry framework, make sure every risk has the right owner, and run a regular working group with the stakeholders.
The asset or service owner responds. Risk response belongs to whoever owns the thing at risk, supported by the same technical group that would respond to an incident on that asset.
The CISO oversees and decides. In Kevin's words, the CISO "sits in the watchtower." Ideally, they chair the working group and make the top-level call: is this residual risk acceptable, yes or no?
Kevin drew on his military security background here. Even the best plan is useless if nobody exercises it, and it needs a standing working group that includes the people who own the thing. A risk program works the same way. If the stakeholders aren't meeting regularly, you're missing important things.
One idea changed how I think about this. Kevin walked me through how a program gets structured:
Until that pairing happens, it's just a template. And the pairing doesn't change because the asset is AI. If your organization uses Microsoft Copilot, Microsoft is the vendor, but someone inside your company still has to own that asset. It's the same as owning a server or a network segment.
This was my biggest objection. Running a risk assessment on every laptop and keyboard sounds like a technical-debt nightmare. Kevin agreed, and that's why the entity framework matters. You map assets to the business and assess at the level that protects what's critical. In practice, that usually means tying risk to a business service.
So I pushed further. Say I run the P&L for packaging and fulfillment. I own the business service, so I own the risk. But I'm a businessperson and can't patch anything myself. Kevin's answer: a service can have multiple owners. The business owner is accountable and makes the decision. A responsible support group with the technical know-how carries out the fix. It's the same group that would show up if there were an incident on those assets.
When I asked about the CISO's real challenge, which is securing the company while still enabling innovation, Kevin's answer was the one he's been giving for years: CMDB health. You have to have it.
You can't protect what you can't see. You also can't route a risk to an owner who isn't recorded anywhere. Accurate configuration data, defined ownership aligned to the Common Service Data Model (CSDM), and working health metrics are what make both security posture and AI readiness possible. As Kevin put it, the pain points of AI readiness are the same ones IT service management has been fighting for years. The core issue is who owns what.
This also takes pressure off risk teams. Even big enterprises often have only four or five risk professionals, usually working with spreadsheets. A defined workflow fixes that. A risk starts in draft. The risk team confirms it's legitimate. The asset owner chooses to mitigate or accept. If they accept, the decision goes to an approval group, usually ending with the business owner or the CISO. The right people see the right thing at the right time.
The usual audit goes like this: an external auditor hands over a spreadsheet of questions, and the team spends weeks digging for evidence. With IRM on ServiceNow, Kevin explained, you tie audits to your ongoing compliance framework and work on compliance all year. When the auditor shows up, you hand over an audit engagement with the evidence already collected.
That's a point I'll make to every CISO from now on. Once you start bringing new assets into ServiceNow, especially OT, ask whether your risk and audit counterparts know what has to happen next. Securing assets is one job. Producing a paper trail that satisfies an audit is another.
Kevin also showed me Unified Security Exposure Management. It's an enterprise view that brings host, application, and container vulnerabilities, configuration compliance, and data loss prevention incidents together in one place. Mature security teams run more than one scanner. With scoring rules, you decide which source to trust when they disagree. Findings then flow into remediation workflows, so one fix can close a thousand vulnerabilities at once.
The connection that matters most is between vulnerabilities and controls. If the security team finds vulnerabilities that materially affect compliance, those findings need to tie back to specific controls on the risk side. Otherwise, the scanner team is working in a silo, and as Kevin said, that's not effective.
The goal is simple to say and hard to do: a risk and security program, linked to the CMDB and the business, should drive business decisions. Do we fund the remediation, or do we accept the risk? Is that call being made at the right level with the right inputs? For the CISO, the job isn't just identifying risk. It's helping the business decide what to do about it.
That's Kevin's favorite line, and it sums up the moment we're in. Everyone is adopting AI. Fewer organizations can say with confidence that they aren't adding risk to their environment. Shadow AI is a real exposure. An AI Control Tower gives you a way to govern AI assets like any other asset: who owns it, what value it delivers, and what controls apply.
If you're planning a security and risk roadmap, here are the questions Kevin would ask first:
Most of all, get every stakeholder in the room from day one: risk, security, IT operations, asset owners, and the business. Kevin has seen too many IRM projects reach UAT before someone asks, "Wait, what about this?"
I came into this conversation asking whether our security practice should lead with risk or whether that would put off the CISO. I left convinced the question was framed wrong. Risk and security are one discipline, with one shared data foundation and one set of owners. The CISO doesn't need to see how every sausage is made. But they do need a program that makes the finished product visible, accountable, and ready for a decision.
That's what we're building at CoreX. If you're facing these same questions, from shadow AI to OT exposure to audit readiness, we'd like to talk.