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

# Security Alert Configuration

> Configure which security event types trigger alerts, set severity thresholds, and enable or disable alert rules for your organization.

Security alert configuration page at `/settings/security-alerts` where administrators define which security events generate alerts, set their severity, and enable or disable individual rules.

## Overview

The Security Alert Configuration page provides a CRUD interface for the `pf_security_alert_configs` table. Each config record specifies an `alert_name`, an `event_type` (one of: `failed_login`, `permission_violation`, `suspicious_activity`, `account_lockout`, `mfa_failure`), a `severity` (one of: `info`, `warning`, `error`, `critical`), and an `is_active` toggle. Admins can create, edit, and delete configurations via dialogs. Delete requires confirmation. The page is gated by `pf.security_alerts.manage`.

## Who it's for

**Required permission:** `pf.security_alerts.manage`

## Before you start

* You must hold the `pf.security_alerts.manage` permission.
* Determine which event types and severity thresholds are relevant to your organization's security posture.

## Steps

1. Navigate to `/settings/security-alerts`.
2. Review existing alert configurations in the table.
3. To add a new alert rule, click **New Alert** and complete the form.
4. To edit an existing rule, click its edit icon.
5. To enable or disable a rule, toggle the **Active** switch on the rule.
6. To remove a rule, click its delete icon and confirm.

## Key concepts

**event\_type** — The security event category that triggers this alert. Available types: `failed_login`, `permission_violation`, `suspicious_activity`, `account_lockout`, `mfa_failure`.

**severity** — The urgency level assigned to the alert: `info`, `warning`, `error`, or `critical`.

**is\_active** — Whether the alert rule is currently evaluating incoming events.

## Built-in default rules

Every organization starts with a set of platform-managed alert rules that fire immediately to in-app notifications when a matching event is recorded. These rules appear in the list but do not belong to your organization, so you cannot edit or delete them — you can add organization-specific rules alongside them.

| Default rule                 | Event type             | Severity | Notifies |
| ---------------------------- | ---------------------- | -------- | -------- |
| Global: Permission violation | `permission_violation` | Any      | In-app   |
| Global: Account lockout      | `account_lockout`      | Any      | In-app   |
| Global: Session hijack       | `session_hijack`       | Any      | In-app   |
| Global: Suspicious activity  | `suspicious_activity`  | Any      | In-app   |
| Global: IP blocked           | `ip_blocked`           | Any      | In-app   |
| Global: Bulk operation       | `bulk_operation`       | Any      | In-app   |
| Global: Config change        | `config_change`        | Any      | In-app   |
| Global: Data export          | `data_export`          | Any      | In-app   |

High-volume event types like `failed_login` and `rate_limit_exceeded` are intentionally excluded from the defaults. Add an organization-scoped rule with a tighter severity filter if you want to alert on them.

## How delivery works

When a security event is recorded for your organization, every active rule whose `event_type` and `severity` filter matches the event triggers a notification. Delivery to the configured channels (currently in-app) happens automatically — you do not need to configure a downstream webhook or notification job.

## Related

<Columns cols={2}>
  <Card title="Platform Foundation" icon="layer-group" href="/pf/overview">
    Platform Foundation overview.
  </Card>

  <Card title="Governance & parity" icon="scale-balanced" href="/governance/index" />
</Columns>

<Note>
  This page documents shipped product behavior. It is not medical, legal, or
  billing advice. Verify against your organization's policies and applicable
  regulations before using it for clinical, compliance, or billing decisions.
  Protected health information (PHI) shown in the product is governed by your
  tenant's access controls and is never exposed in this documentation.
</Note>

<Accordion title="Documentation sources">
  * src/routes/platform.tsx
  * src/platform/security/pages/SecurityAlertConfigPage.tsx
  * src/platform/security/hooks/useSecurityAlertConfigList.ts
</Accordion>