How should SecOps, red teams and vulnerability management share responsibility for CTEM?

How CTEM responsibility should be split across SecOps, red teams and vulnerability management

CTEM works best when the teams do different jobs against one shared prioritisation model. SecOps should own the validated risk picture, red teams should test how real attack paths behave, and vulnerability management should drive remediation. The operating rule is simple: one accountable function must reconcile those inputs into a single version of truth for action.

What each function contributes to CTEM

SecOps is the natural owner of the final prioritisation view because it sees detection, control performance and response together. That matters when the same weakness has different operational meaning depending on whether it is observable, blocked, or already being exploited. CTEM becomes noisy if this function is only one voice among several instead of the place where signals are reconciled.

Red teams contribute adversarial realism. Their value is not in producing more findings, but in showing which weaknesses can be chained, bypassed or used to reach a higher-impact objective. That attack perspective should sharpen the prioritisation model, not replace the operational view that SecOps uses to decide what is truly exposed.

Vulnerability management owns the execution side of the loop. It is responsible for intake, validation, assignment, remediation tracking and closure evidence, which is why it often has the best view of patch velocity and exception drift. A CTEM programme fails when remediation is treated as the whole problem, because fixing tickets without a validated risk model can still leave the highest-exposure path untouched.

Where shared responsibility usually breaks down

CTEM breaks when each team optimises for its own artefact. Red teams can produce technically excellent findings that are hard to operationalise, vulnerability management can focus on volume reduction rather than exploitability, and SecOps can overvalue what is most visible in telemetry. The result is three versions of priority, none of which is authoritative on its own.

The shared model has to reflect reality at the point of decision. That means validated exposure, compensating controls, exploitability, business impact and response readiness must all converge before something is called top priority. If the teams disagree on the facts, the answer is not a committee vote, it is to identify which function owns the final evidence set and the tie-break.

The CVE Program helps only as an identifier layer, not as the prioritisation model itself. Likewise, SecOps should not wait for remediation completion before updating risk, because live detection and control telemetry may already show that a flaw is contained, being probed, or actively exploited.

How to make the operating model work in practice

Set one decision owner for the final CTEM queue, usually SecOps or a SecOps-led risk function, and require the other teams to feed that queue with their specialist evidence. Red team output should be translated into attack-path language, not left as standalone findings. Vulnerability management should then own the remediation workflow for whatever that queue surfaces, with clear severity and due-date rules.

The cleanest handoff is: red teams validate how an issue can be abused, SecOps validates whether the issue is already detectable or partially controlled, and vulnerability management executes the fix and proves closure. That sequence avoids the common failure mode where a patch is rushed for the loudest issue while a more dangerous chained path remains open.

For a broader operational baseline, the CIS Controls v8 provide a useful way to anchor vulnerability management, account management and logging disciplines, while the NIST Cybersecurity Framework 2.0 is helpful for aligning govern, identify, detect and respond responsibilities around a single risk picture.

Risk and Threat Considerations

CTEM fails when responsibility is split but accountability is not. That creates stale prioritisation, duplicated work and blind spots where an exploitable issue is known to one team but not reflected in the operational risk picture. The danger is greatest when teams treat findings as separate inventories instead of one adversarially tested exposure model.

Failure mechanism: Different teams use different evidence standards, so the organisation ends up with conflicting severity, conflicting deadlines and an inaccurate view of what an attacker can actually reach.

Impact: The organisation may remediate low-value issues first, miss chained attack paths, and believe it is reducing risk when exposure is unchanged or even increasing.

Practitioner Guidance

What to prioritise: Establish a single final prioritisation owner and make every CTEM input answer to that owner’s risk model. If a finding cannot be expressed as exposure, control gap, exploit path or response consequence, it is not ready for the queue.

Decision rule: If red team evidence and vulnerability management data point in different directions, defer the action only long enough for SecOps to reconcile them into one validated view, then move forward on that view rather than preserving parallel truths.

What to measure: Track how many findings change priority after validation, how many top risks have an agreed owner, and how long it takes to move from discovery to a remediation decision. Those signals show whether CTEM is operating as a decision system or just a reporting pipeline.

Practitioner takeaway: CTEM only works when attack realism, operational telemetry and remediation execution are merged into one accountable prioritisation process, not managed as three separate truths.

Related resources from NHI Mgmt Group

• Who should own vulnerability remediation when multiple cloud teams share responsibility?
• What do security teams get wrong when they treat CTEM as simple vulnerability management?
• How should IT teams share responsibility for macOS patching across admins, users, and management?
• Who should own SCIM-driven account provisioning when identity and password management teams share responsibility?