Mitigation & Remediation in Cyrisma

Mitigation and remediation in Cyrisma are designed to help organizations reduce risk in a controlled, auditable, and repeatable manner. Rather than relying on a single remediation mechanism, Cyrisma provides multiple, intentionally distinct paths for addressing risk—each serving a different operational or governance purpose.

This article explains:

• What remediation means in Cyrisma

• The remediation mechanisms available

• How mitigation plans, patching, and suppressions differ

• Why these mechanisms are intentionally decoupled

• How to choose the appropriate remediation approach

This article serves as the conceptual foundation for all mitigation- and remediation-related documentation in the Cyrisma Knowledge Base.

What Remediation Means in Cyrisma

In Cyrisma, remediation is the act of addressing risk identified by scans. Risk may originate from:

• Vulnerable software

• Insecure system configurations

• Sensitive data exposure

• Non-compliant security settings

Remediation does not always mean immediate technical change. In practice, remediation may involve:

• Applying patches

• Correcting configuration issues

• Securing, encrypting, or removing sensitive data

• Tracking remediation work for accountability

• Accepting or suppressing risk when appropriate

Cyrisma supports these outcomes through three distinct remediation mechanisms.

The Three Remediation Paths

Patch Manager (Direct Remediation)

Patch Manager is Cyrisma’s execution layer for remediation.

It is used to:

• Apply patches for supported third-party applications

• Apply Windows KB updates

• Remediate certain security configuration findings

Key characteristics:

• Executes remediation actions directly on endpoints through agents

• Relies on scan results to determine applicable patches

• Operates independently of mitigation plans

• Does not modify historical scan results

Patch Manager is best suited for technical remediation where changes can be applied automatically or at scale.

Mitigation Plans (Governance and Tracking)

Mitigation Plans provide a structured way to manage, assign, and document remediation efforts based on scan results.

They are used to:

• Assign ownership for remediation activities

• Track actions taken against vulnerabilities, configurations, or data findings

• Document remediation decisions and outcomes

• Provide audit and compliance evidence

Key characteristics:

• Created from completed scan results

• Scan-based and static by design

• Require users to explicitly document actions taken

• Automatically complete once all items are addressed

Mitigation plans are intentionally decoupled from execution. This allows organizations to track remediation work regardless of how the fix was performed, whether through Patch Manager, manual changes, or external tooling.

Suppressions (Risk Acceptance)

Suppressions represent a formal decision to exclude specific findings from future scan results for a defined period.

They are used when:

• A finding is expected or acceptable

• A risk cannot be remediated immediately

• A finding is not relevant in a specific context

Key characteristics:

• Can be applied locally (per host) or globally (per instance)

• Have a configurable expiration period (30, 60, or 90 days)

• Remove suppressed items from future scan results

• Can be applied directly from scan results or within mitigation plans

Suppressions are not remediation. They are a documented form of risk acceptance.

Why These Mechanisms Are Intentionally Decoupled

Cyrisma separates execution, tracking, and risk acceptance to ensure accuracy, accountability, and auditability.

Key design principles:

• Scan results are immutable
  Historical scans represent a point-in-time snapshot and are never modified after remediation occurs

• Patching does not automatically close mitigation plans
  Remediation actions must be explicitly documented by the user responsible for the mitigation plan

• Governance must not rely solely on automation
  Mitigation plans exist to provide ownership, evidence, and accountability even when remediation occurs outside Cyrisma

This design prevents false assumptions about remediation status and ensures reliable historical records.

Choosing the Right Remediation Path

In many environments, multiple approaches are used together. For example:

• Apply a patch using Patch Manager

• Document the remediation in a mitigation plan

• Temporarily suppress a finding while remediation is pending

Summary

Cyrisma provides a flexible, auditable remediation framework built on three core mechanisms:

• Patch Manager for direct remediation

• Mitigation Plans for governance and tracking

• Suppressions for controlled risk acceptance

Understanding how these mechanisms work together, and why they are intentionally separate, is essential for accurately managing risk and maintaining a defensible security posture in Cyrisma.