Who owns what?
Every asset needs a named owner, and every owner needs to know they are one. In a group, set ownership at the entity level first, a subsidiary or brand, and then at the team level. When the tool attributes a new asset to an entity, a named contact in that entity should confirm or reject it within an agreed time. Assets nobody confirms go to a short review list, not into the main queue.
Keep the owner field in the system your teams already use. Most tools in our ranking document ticketing integrations, such as Jira and ServiceNow, so the finding can arrive where the owner works.
Who approves active testing?
Validation sends traffic to production systems. Methods differ by vendor: IONIX describes non-intrusive exploit simulations, CyCognito says its tests avoid brute force and state changes, and watchTowr and Hadrian describe attack agents. Whatever the method, agree in writing:
- which assets and entities are in scope for active tests;
- which systems are excluded, such as fragile legacy applications;
- who is notified before and during testing;
- how assets that may belong to a supplier are handled, since they are not yours to test.
Who approves automated mitigation?
Some tools can push a rule to a WAF or edge platform. IONIX describes deployable WAF rules delivered into remediation workflows, watchTowr describes Active Defense rules pushed through edge vendors, and Cortex Xpanse describes Active Response playbooks. A rule that blocks an attack can also block customers, so set the approvals first: who signs off, whether new rules start in monitor or log-only mode, how a rule is rolled back, and a review date on every rule so they do not pile up after the code is fixed. Our note on virtual patching covers this in more detail.
What service levels should you set?
| Finding class | Decision needed | Suggested target to agree internally |
|---|---|---|
| Validated exploitable on an internet-facing asset | Fix or apply a compensating control | The shortest target you can meet reliably |
| Matches a KEV entry on an internet-facing asset | Confirm exposure, then fix or mitigate | Aligned with your KEV policy |
| High EPSS probability, not validated | Validate or schedule | Within your normal patch cycle |
| Everything else | Order by severity and business context | Maximum age before review |
The table gives structure, not numbers. The right targets depend on your change process; the point is that each class has one and that it is measured. The next lesson covers how.
How often should the program review itself?
Weekly for open validated and KEV-listed exposures, monthly for ownership gaps and assets awaiting confirmation, and quarterly for scope: new acquisitions, divestments and changes to the tool's configuration. Tie the quarterly review to the corporate development calendar, because a new acquisition is the most reliable source of unknown assets.
Terms in this lesson: Asset owner, Log-only mode, Virtual patching, KEV, Mean time to remediate (MTTR)
Sources: IONIX, Exposure Validation, CyCognito, Active Security Testing, watchTowr, Platform, Hadrian, Technology, IONIX, WAF Posture Management, Palo Alto Networks, Cortex Xpanse, CISA, Known Exploited Vulnerabilities catalog