Cybersecurity conversations often separate the control environment from the operating environment. One team owns identity, another owns applications, a supplier owns an integration, and an executive committee reviews risk on a quarterly cadence. The incident, however, experiences none of those boundaries. It appears as a service interruption, a corrupted decision, a lost patient record, a delayed public benefit, or a customer who no longer trusts the organization.
CISA’s Cross-Sector Cybersecurity Performance Goals are useful because they focus on a prioritized set of practices with known risk-reduction value and connect information technology and operational technology concerns. They are voluntary and not a complete security program. Their real value is managerial: they give leaders a common starting point for deciding which capabilities deserve investment and how progress should be observed.
Controls are only useful when the service can carry them
Multi-factor authentication is not only an identity control. It changes onboarding, break-glass access, contractor experience, help-desk work, and incident response. Asset inventory is not only a compliance artifact. It changes the organization’s ability to find a vulnerable dependency, understand blast radius, and restore a critical service. Logging is not simply storage. It is the raw material for detection, explanation, and learning.
The strategic implication is that security must be designed with the service. For each critical capability, leaders should be able to see:
- the users, systems, suppliers, and identities that make the service possible;
- the conditions under which the service can operate in a degraded mode;
- the signals that indicate a material change in risk;
- the owner who can authorize containment or recovery;
- the evidence that proves the service is ready for the next operating condition.
This is the difference between a control catalog and a resilience system. One lists practices. The other makes the consequence of a practice visible to the people responsible for keeping the organization moving.
Make the safe path the usable path
Security programs lose trust when the safest option is also the least practical. Teams route around controls because the approved path is too slow, too opaque, or too disconnected from the work. Platform teams can help by turning security requirements into reusable patterns: approved identity flows, policy-as-code, observable deployment paths, data classifications that travel with the asset, and recovery exercises that are treated as part of service ownership.
This requires product thinking. A platform should make a promise to its users: what it makes easier, what it guarantees, what evidence it provides, and what responsibility remains with the product team. A security service should do the same. When the promise is clear, adoption becomes measurable and exceptions become a design input rather than a hidden source of risk.
A practical diagnostic
Choose one service that executives would protect first during a disruption. Trace its data, identities, third parties, deployment path, and recovery sequence. Then ask a person outside the security function to explain what they would do if the service were compromised. The gaps between the formal plan and the usable answer are the operating model work.
Measure security in terms leaders can manage: time to detect a material change, time to contain, time to restore the service, percentage of critical assets with an accountable owner, recovery exercise findings closed on time, and the number of high-risk exceptions with an explicit expiration. These measures do not replace technical control testing. They connect control performance to organizational consequence.
What would change our mind?
Not every service needs the same control intensity, and not every CISA goal is equally urgent for every organization. A small, low-consequence internal tool should not inherit the same burden as a public benefit system or a clinical platform. The disciplined approach is proportionality: classify the service, make the consequence visible, select the controls that change that consequence, and revisit the decision as the service or threat changes.
Cybersecurity becomes a source of advantage when it helps leaders move with confidence. That confidence is not produced by saying the organization is secure. It is produced by knowing how the important services behave, how they fail, who can act, and how quickly learning reaches the next decision.