Summary

This work starts with a question that often appears after an organization has accumulated tools, projects, and controls over several years:

How do we organize cybersecurity so decisions begin with what the organization needs to be able to do rather than with the inventory of products it already owns?

The answer I have been structuring is a model centered on capabilities.

In this context, a capability is an organizational ability that combines people, processes, controls, information, technology, and governance to produce a security outcome with enough repeatability and measurability to be managed.

Technology remains important.

It simply stops being the primary design unit.

The starting problem

When the conversation is organized around tools, questions often sound like:

  • what does this platform do?;
  • what module are we missing?;
  • which vendor covers this function?;
  • which license should we renew?;
  • what new integration can we add?

Those are legitimate questions, but they do not necessarily reveal whether the organization is better prepared to manage risk.

An architecture can contain technically strong controls and still have gaps between:

  • detection and decision;
  • alert and response;
  • backup and recovery;
  • vulnerability and remediation;
  • policy and operations;
  • technology and evidence.

So the design problem was not to create another catalog.

It was to build a logic that connects business, risk, capability, enablers, and evidence.

Guiding principle

The principle behind the work is:

The organization should first be able to explain what it needs to be capable of doing; then it can decide what processes, controls, and technologies are needed to sustain that capability.

This does not remove products or services.

It places them inside a broader decision architecture.

01 — Start with business context

The first layer is not technical.

It looks at elements such as:

  • important processes;
  • services that must remain available;
  • sensitive information;
  • assets and dependencies;
  • relevant third parties;
  • regulatory constraints;
  • tolerance for disruption;
  • decision owners.

The objective is not to build a perfect enterprise map.

It is to have enough context to avoid designing capabilities disconnected from what actually matters.

02 — Translate context into exposure and risk

After context, the questions move toward scenarios:

  • what can fail?;
  • what can be compromised?;
  • what exposure exists?;
  • what dependencies amplify impact?;
  • what threats are plausible?;
  • what existing controls reduce risk?;
  • what uncertainty still remains?

This layer prevents a technology choice from becoming the starting point before the problem is understood.

03 — Turn risk into a capability decision

The next step is to describe the need without naming a product yet.

For example, the organization may need to be able to:

  • detect relevant signals with enough context;
  • reduce exposure on critical assets;
  • contain a compromised account;
  • recover information and services;
  • validate that a control works;
  • prioritize remediation;
  • manage exceptions;
  • retain evidence for decisions and learning.

The wording matters because it allows different technology alternatives to be compared against the same objective.

04 — Define the capability as a system

A capability should not be reduced to software.

For every relevant capability, the model asks:

Purpose

What risk or scenario does it change?

Owner

Who is accountable for its operation?

Participants

Which teams or third parties are involved?

Process

What sequence of actions needs to happen?

Decisions

What criteria determine priority, escalation, acceptance, or response?

Controls

What preventive, detective, corrective, or recovery mechanisms participate?

Information

What data and context does the capability need to operate?

Technology

What platforms enable or automate parts of the process?

Evidence

What demonstrates that the capability exists and works?

Validation

How do we test whether it responds when the scenario occurs?

This structure helps expose gaps that are invisible when the inventory is limited to products.

05 — Make technology subordinate to the problem, not unimportant

A bad interpretation of the model would be that technology matters less.

It does not.

Technology can determine:

  • coverage;
  • speed;
  • precision;
  • automation;
  • visibility;
  • scalability;
  • integration capacity;
  • quality of evidence.

The change is in the order of decisions.

First, clarify the capability that is needed.

Then evaluate which technology strengthens it best within real constraints.

06 — Evaluate technology enablers with operating criteria

When technology is evaluated, the model looks beyond functionality.

It also considers:

  • fit for the use case;
  • integration with the environment;
  • operating effort;
  • required skills;
  • lifecycle cost;
  • dependency on third parties;
  • recovery capability;
  • data quality and portability;
  • interoperability;
  • ability to validate the control;
  • ability to evolve or replace the solution.

This helps avoid architectures that are technically attractive but difficult to sustain.

07 — Connect capabilities to one another

Security capabilities rarely operate in isolation.

An exposure signal can become a remediation priority.

A detection can trigger response.

A response may depend on identity, endpoint, email, network, backup, or communications.

A recovery event may reveal a design weakness that must return to the improvement cycle.

So the model pays attention to the handoffs:

signal → context → decision → action → evidence → learning

Many operational failures happen precisely between tools or teams that appear to work well individually.

08 — Design evidence from the beginning

A capability should not be assessed only by its declared existence.

It needs to produce useful evidence.

Depending on the case, that may include:

  • coverage;
  • relevant events;
  • decision or response times;
  • actions taken;
  • exceptions;
  • validation results;
  • tested restores;
  • recurring findings;
  • residual risk;
  • pending decisions.

Not every indicator applies to every capability.

The important point is to define what signals will help determine whether the capability is actually working and improving.

09 — Validate before trusting

An approved policy, a green dashboard, or an installed agent does not by itself prove that a scenario is controlled.

That is why the model treats validation as a cross-cutting discipline:

  • technical tests;
  • exercises;
  • simulations;
  • evidence reviews;
  • restorations;
  • rescans;
  • follow-up on corrective actions.

Validation reduces the distance between believing we have a capability and having evidence that it can be executed.

10 — Evolve without rebuilding everything from scratch

A capability-based architecture allows products, providers, or implementations to change without redefining the objective completely.

If risk changes, the capability can adapt.

If a tool is no longer appropriate, it can be replaced while preserving:

  • purpose;
  • ownership;
  • process;
  • decision criteria;
  • expected evidence;
  • validation mechanisms.

That makes strategy less dependent on one specific technology snapshot.

A compact view of the model

The logic can be summarized as:

business context → exposure and risk → priority → required capability → processes and controls → technology enabler → evidence → validation → learning

It is not a contractual formula and it is not intended to be a rigid sequence for every scenario.

It is a thinking architecture for keeping decisions connected when they would otherwise become fragmented.

Relationship to my work at ActivosTI

A meaningful part of this reasoning took shape while working on the evolution of ActivosTI toward a cybersecurity approach organized around strategic cyber-resilience capabilities, rather than presenting technology as an isolated catalog.

On the personal site, I do not reproduce ActivosTI’s commercial portfolio or operating method.

What I document here is the transferable reasoning I find valuable: start with context and risk, decide what capability needs to be strengthened, use technology as an enabler, and require evidence to learn and improve.

What this approach tries to avoid

Buying before defining the problem

Product selection happens before there is clarity about the scenario that needs to change.

Confusing deployment with capability

The project ends when the technology is installed even though operations still lack ownership, procedure, or validation.

Duplicating tools to compensate for process problems

Another platform is added when the actual gap is in decisions, integration, data, or accountability.

Designing an architecture the team cannot operate

The solution is technically sound, but complexity exceeds available capacity.

Measuring activity without testing effectiveness

Licenses, alerts, or completed tasks are reported without connecting them to exposure, response, recovery, or residual risk.

Role

My work in this piece focused on:

  • separating capability from product;
  • connecting business context with cybersecurity decisions;
  • structuring a risk → capability → enablers → evidence logic;
  • identifying the minimum components of an operable capability;
  • adding technology-strategy criteria beyond functionality;
  • making dependencies between capabilities visible;
  • integrating validation and learning;
  • keeping the model independent of specific vendors.

Result

The result is a decision model that helps move from a conversation like:

What tools do we have or should we buy?

toward a more useful one:

What does the organization need to be able to do, what risk does that capability change, and what combination of people, processes, controls, and technology can sustain it?

It does not attempt to eliminate complexity or produce one universal answer.

Its purpose is to make decisions clearer, more traceable, and more defensible.

Learnings

  • an excellent tool can still be poorly positioned inside the operating architecture;
  • a capability should be explainable without starting with a vendor;
  • people and process are not later additions: they are part of the design;
  • integration matters as much as isolated functionality;
  • operating complexity must be treated as a real constraint;
  • evidence and validation should be designed rather than improvised at the end;
  • capability-based architecture makes it easier to evolve technology without losing purpose;
  • technology strategy improves when each investment can be connected to a need and a risk decision.

A practical conclusion

Technology will remain an essential part of cybersecurity.

But an organization gets more value when it can explain:

what risk it is managing → what it needs to be able to do → what technology enables that capability → what evidence demonstrates that it works.

That change in order turns a collection of tools into a capability architecture.