Skip to main content

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: