Capabilities and Architecture Planning and Operating Model Design

A security team can be busy, capable, and still quietly misaligned. Roles accrete over years, people cover for each other, and the org chart slowly stops describing who is actually accountable for what. Leaders often sense the drift long before they can prove it.

That was the situation for this client, a global B2B information services group. Its security leadership suspected the team’s capabilities no longer mapped cleanly to accountability, but had no evidence to act on.

The approach

KASP ran a structured capabilities architecture exercise across the InfoSec function. Rather than imposing a top-down opinion, we surveyed every member of the team on each capability they touched: who owned it, how mature it was, and whether they were a producer or a consumer of it.

What we found

Roughly a third of the function’s capabilities had no clear owner at all. Worse, the capabilities in highest demand, such as regulatory compliance management and security risk assessment for new products, were also among the least mature. And several unowned capabilities sat entirely outside the security team’s formal oversight, which raised the question that tends to concentrate a board’s attention: who is accountable if one of them fails in the middle of an incident?

Why it mattered

The client did not need another maturity score to file away. They needed to know where to act first. What KASP delivered was a data-backed map of exactly where ownership had to be assigned, in priority order, and the internal evidence to make that case to the rest of the business.

Capability without clear ownership is not capability you can rely on. Naming it, and naming who holds it, is the first step to being able to trust it.