Ownership & Routing
Cloudaware uses CMDB relationships to determine who is responsible for fixing each vulnerability and where remediation work should be routed (e.g., to a specific team or ticket queue).
Use this guide to understand how ownership is derived and used to route vulnerabilities for remediation, ticketing, and escalation.
Ownership Sources
Ownership is typically derived from:
- Asset owners – fields on server, container, or cloud resource CIs.
- Application/Service owners – records that group assets into logical services or products.
- Organization Units (OUs)/Teams – higher‑level groupings used for reporting and escalation.
Cloudaware’s routing logic can:
- Inherit ownership from the most specific entity (e.g., application over OU).
- Fall back to default owners for shared or unassigned infrastructure.
Routing Use Cases
Ownership information is used to:
- Assign vulnerabilities to the correct application or platform team.
- Create ITSM tickets in the right queues or projects.
- Group vulnerabilities into Remediation Tasks and Initiatives (see Processes).
- Drive escalation reports by OU or application.
Best Practices
- Keep application and OU mappings up to date in CMDB.
- Establish clear defaults for:
- Unowned assets.
- Shared platforms like databases, load balancers, or shared clusters.
- Avoid over‑routing everything to a central SecOps queue; instead, use SecOps as approvers and coaches while application teams own fixes.
Relationship to Exceptions and SLAs
Ownership and routing interact with other parts of the model:
- Exceptions – when an exception is granted, the related findings are marked suppressed but still retain ownership for auditability.
- SLAs – severity and risk bands determine due dates per owner, OU, or application.
See also: