> ## Documentation Index
> Fetch the complete documentation index at: https://docs.alignr.io/llms.txt
> Use this file to discover all available pages before exploring further.

# Vulnerabilities and governance

> Scanned findings, missing patches and operational security reviews.

This category contains **5 automated control definitions** and **3 manual checks** across the sources named below. Similar controls from different standards are listed separately because names, thresholds or severity can differ.

Whether the seeded Alignr Baseline is available depends on how your workspace was provisioned. Library templates are copied as disabled drafts. See [Choose a baseline](/controls/baselines/overview) before enabling anything.

## Automated controls

Expand a control to see the exact population, expectation and defaults. A pass requires usable evidence for the selected population. A known contrary observation can prove failure; missing observations or an empty population must not become a pass.

<AccordionGroup>
  <Accordion title="No open critical vulnerabilities">
    <Tabs sync={false}>
      <Tab title="Explanation">
        The recorded maximum vulnerability severity should not be critical.

        Part of **Alignr Baseline (seeded)**.

        **Applies to**

        Subjects with a recorded highest vulnerability severity observation.

        **What the result tells you**

        This excludes the exact value critical. A non-critical value does not mean zero vulnerabilities, and absent severity evidence does not pass.
      </Tab>

      <Tab title="Definition">
        | Setting           | Value                    |
        | ----------------- | ------------------------ |
        | Standard          | Alignr Baseline (seeded) |
        | Severity          | High                     |
        | Declared autonomy | Suggest only             |

        **Population condition**

        **Highest vulnerability severity** (`vulnerability_max_severity`) has an observation.

        **Expected evidence**

        * **Highest vulnerability severity** (`vulnerability_max_severity`) does not equal `"critical"`.

        **Required predicates:** `vulnerability_max_severity`.

        ```json theme={null}
        {
          "match": {
            "predicate": "vulnerability_max_severity"
          },
          "expect": [
            {
              "fact": "vulnerability_max_severity",
              "op": "neq",
              "value": "critical"
            }
          ],
          "severity": "high",
          "title": "Scanned host has an open critical vulnerability",
          "evidence": [
            "vulnerability_max_severity"
          ]
        }
        ```
      </Tab>
    </Tabs>
  </Accordion>

  <Accordion title="Open vulnerability count stays within limits">
    <Tabs sync={false}>
      <Tab title="Explanation">
        The recorded open-vulnerability count should be at or below the configured limit.

        Part of **Alignr Baseline (seeded)**.

        **Applies to**

        Subjects with a recorded open vulnerability count observation.

        **Default settings**

        | Setting                      | Default | Allowed range |
        | ---------------------------- | ------- | ------------- |
        | Maximum open vulnerabilities | `5`     | 0–1000        |

        Client overrides can change these values. [Check the effective settings](/controls/parameters) when interpreting a result.

        **What the result tells you**

        The limit applies to the source-reported count for a subject. Keep scanner scopes comparable; a low count is not proof of low business risk.
      </Tab>

      <Tab title="Definition">
        | Setting           | Value                    |
        | ----------------- | ------------------------ |
        | Standard          | Alignr Baseline (seeded) |
        | Severity          | Medium                   |
        | Declared autonomy | Suggest only             |

        **Population condition**

        **Open vulnerability count** (`vulnerability_open_count`) has an observation.

        **Expected evidence**

        * **Open vulnerability count** (`vulnerability_open_count`) is at most parameter `max_open_vulnerabilities`.

        **Required predicates:** `vulnerability_open_count`.

        ```json theme={null}
        {
          "match": {
            "predicate": "vulnerability_open_count"
          },
          "expect": [
            {
              "fact": "vulnerability_open_count",
              "op": "lte",
              "value": {
                "param": "max_open_vulnerabilities"
              }
            }
          ],
          "severity": "medium",
          "title": "Scanned host exceeds the open-vulnerability limit",
          "evidence": [
            "vulnerability_open_count"
          ]
        }
        ```
      </Tab>
    </Tabs>
  </Accordion>

  <Accordion title="Managed endpoints have no missing patches">
    <Tabs sync={false}>
      <Tab title="Explanation">
        The selected device needs an explicit null observation for missing patches to satisfy this comparison.

        Part of **Alignr Baseline (seeded)**.

        **Applies to**

        Devices reported as managed by an RMM.

        **What the result tells you**

        Important limitation: not\_exists compares an observed null value. No missing\_patch row is unknown, not a clean patch result. An observed missing patch fails; do not use a lack of rows as proof that the endpoint is patched.
      </Tab>

      <Tab title="Definition">
        | Setting           | Value                    |
        | ----------------- | ------------------------ |
        | Standard          | Alignr Baseline (seeded) |
        | Severity          | High                     |
        | Declared autonomy | Change ticket            |

        **Population condition**

        **Device management** (`device_managed_by`) equals `"rmm"`.

        **Expected evidence**

        * **Missing patch** (`missing_patch`) has an observed null value.

        **Required predicates:** `device_managed_by`, `missing_patch`.

        ```json theme={null}
        {
          "match": {
            "predicate": "device_managed_by",
            "object": "rmm"
          },
          "expect": [
            {
              "fact": "missing_patch",
              "op": "not_exists"
            }
          ],
          "severity": "high",
          "title": "Managed endpoint has an outstanding missing-patch finding",
          "evidence": [
            "device_managed_by",
            "missing_patch"
          ]
        }
        ```
      </Tab>
    </Tabs>
  </Accordion>

  <Accordion title="No critical vulnerabilities remain open">
    <Tabs sync={false}>
      <Tab title="Explanation">
        The recorded maximum vulnerability severity should not be critical.

        Part of **BIOS Vulnerability and Governance**.

        **Applies to**

        Subjects with a recorded highest vulnerability severity observation.

        **What the result tells you**

        This excludes the exact value critical. A non-critical value does not mean zero vulnerabilities, and absent severity evidence does not pass.
      </Tab>

      <Tab title="Definition">
        | Setting           | Value                             |
        | ----------------- | --------------------------------- |
        | Standard          | BIOS Vulnerability and Governance |
        | Severity          | High                              |
        | Declared autonomy | Suggest only                      |

        **Population condition**

        **Highest vulnerability severity** (`vulnerability_max_severity`) has an observation.

        **Expected evidence**

        * **Highest vulnerability severity** (`vulnerability_max_severity`) does not equal `"critical"`.

        **Required predicates:** `vulnerability_max_severity`.

        ```json theme={null}
        {
          "match": {
            "predicate": "vulnerability_max_severity"
          },
          "expect": [
            {
              "fact": "vulnerability_max_severity",
              "op": "neq",
              "value": "critical"
            }
          ],
          "severity": "high",
          "title": "Critical vulnerability remains open",
          "evidence": [
            "vulnerability_max_severity"
          ]
        }
        ```
      </Tab>
    </Tabs>
  </Accordion>

  <Accordion title="Open vulnerabilities stay below threshold">
    <Tabs sync={false}>
      <Tab title="Explanation">
        The recorded open-vulnerability count should be at or below the configured limit.

        Part of **BIOS Vulnerability and Governance**.

        **Applies to**

        Subjects with a recorded open vulnerability count observation.

        **Default settings**

        | Setting                      | Default | Allowed range |
        | ---------------------------- | ------- | ------------- |
        | Maximum open vulnerabilities | `5`     | 0–1000        |

        Client overrides can change these values. [Check the effective settings](/controls/parameters) when interpreting a result.

        **What the result tells you**

        The limit applies to the source-reported count for a subject. Keep scanner scopes comparable; a low count is not proof of low business risk.
      </Tab>

      <Tab title="Definition">
        | Setting           | Value                             |
        | ----------------- | --------------------------------- |
        | Standard          | BIOS Vulnerability and Governance |
        | Severity          | Medium                            |
        | Declared autonomy | Suggest only                      |

        **Population condition**

        **Open vulnerability count** (`vulnerability_open_count`) has an observation.

        **Expected evidence**

        * **Open vulnerability count** (`vulnerability_open_count`) is at most parameter `maximum`.

        **Required predicates:** `vulnerability_open_count`.

        ```json theme={null}
        {
          "match": {
            "predicate": "vulnerability_open_count"
          },
          "expect": [
            {
              "fact": "vulnerability_open_count",
              "op": "lte",
              "value": {
                "param": "maximum"
              }
            }
          ],
          "severity": "medium",
          "title": "Host exceeds vulnerability threshold",
          "evidence": [
            "vulnerability_open_count"
          ]
        }
        ```
      </Tab>
    </Tabs>
  </Accordion>
</AccordionGroup>

## Manual checks

These are human reviews, not automated evidence. The interval below is the template default; review ownership, evidence and suitability for the client.

<AccordionGroup>
  <Accordion title="Review configuration drift governance">
    **Review every 30 days** · BIOS Vulnerability and Governance

    Review approved baselines, exception ownership and drift evidence across systems. Current facts do not prove a complete cross-domain baseline.

    **Record:** who performed the review, when it was performed, the evidence, the conclusion and any follow-up or approved exception. A due review is not evidence of a completed review.
  </Accordion>

  <Accordion title="Review incident response readiness">
    **Review every 90 days** · BIOS Vulnerability and Governance

    Confirm contacts, roles, escalation paths, communications and exercise evidence are current.

    **Record:** who performed the review, when it was performed, the evidence, the conclusion and any follow-up or approved exception. A due review is not evidence of a completed review.
  </Accordion>

  <Accordion title="Review email security posture">
    **Review every 30 days** · BIOS Vulnerability and Governance

    Review SPF, DKIM, DMARC, threat protection, forwarding and audit retention in the source consoles. Current emitted mail facts do not prove the full set of expectations.

    **Record:** who performed the review, when it was performed, the evidence, the conclusion and any follow-up or approved exception. A due review is not evidence of a completed review.
  </Accordion>
</AccordionGroup>

## Investigate a result

Confirm the client and the account, device or other item being assessed. Check the source, observation time and effective settings, then compare the recorded evidence with the expectation. Missing evidence needs investigation; a change to the environment requires a separate review.

## Next steps

[Create a custom control](/controls/create-custom) · [Parameters and client overrides](/controls/parameters) · [Record a manual check](/controls/manual-checks)
