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

# Security Alerts

> Real-time alerting for critical audit events and behavioral anomalies across authentication, files, rooms, users, DLP, KMS, and storage.

## Overview

Enclave runs two parallel alerting engines on top of every audit event:

* **Policy Alerts** — fire when a specific audit action occurs (e.g. a room is deleted, a user's role changes). Configured at **Security → Policies → Alert Policies**.
* **Behavioral Anomaly Detection** — fire when a user's file-access pattern deviates from their baseline (bulk downloads, access from a new country, off-hours activity). Configured at **Security → Alert Policies → Rules**.

Both engines write to the same alert dashboard (**Security → Alerts**) and send in-app notifications, email, and Slack messages to all active Owners and Security Officers in the tenant.

***

## Policy Alerts

### How they work

Every audit log entry passes through the policy alert engine immediately after it is persisted. The engine compares the event against the tenant's active alert policy set. If a matching enabled policy is found — and the policy's cooldown period has not elapsed — an alert is created and notifications are sent.

### System defaults

Eleven policies are active out of the box. Policies marked **System** are platform-required controls — they cannot be deleted. Disabling one shows a compliance warning in the UI and records the action in the audit log.

| Policy                        | Category       | Severity | System | Enabled by Default | Cooldown |
| ----------------------------- | -------------- | -------- | ------ | ------------------ | -------- |
| KMS Connection Deleted        | KMS            | Critical | Yes    | Yes                | None     |
| Storage Configuration Deleted | Storage        | Critical | Yes    | Yes                | None     |
| Room Deleted                  | Secure Rooms   | Critical | Yes    | Yes                | 1 hour   |
| User Status Changed           | Users & Access | High     | Yes    | Yes                | 30 min   |
| User Role Changed             | Users & Access | High     | Yes    | Yes                | 30 min   |
| Storage Disabled              | Storage        | High     | Yes    | Yes                | 1 hour   |
| KMS Encryption Policy Removed | KMS            | High     | Yes    | Yes                | 1 hour   |
| DLP File Quarantined          | DLP            | Medium   | No     | Yes                | None     |
| Secret Viewed                 | Secrets        | Medium   | No     | Yes                | 1 hour   |
| User Invited                  | Users & Access | Low      | No     | No                 | None     |
| Room Member Added             | Secure Rooms   | Low      | No     | No                 | None     |

<Note>
  System policies cannot be deleted. They can be disabled individually, but doing so triggers a compliance warning and is recorded in the audit log for review.
</Note>

### Alert cooldown

When a policy has a cooldown configured, subsequent matches for the same event within that window do not create duplicate alerts. This prevents notification fatigue during sustained incidents — for example, a bulk-deletion event that would otherwise fire hundreds of individual alerts within seconds.

Cooldown is per-tenant and resets independently for each organisation.

### Managing policies

Go to **Security → Policies → Alert Policies** to:

* Toggle individual policies on or off
* Adjust the severity level per policy
* Change or remove the cooldown period
* Add a custom policy for any event in the supported catalog

To add a custom policy, click **Add Policy** and select an event from the searchable event picker, then set a name, severity, and optional cooldown. The picker groups events by category and shows a description of what each event represents so you can choose accurately.

Custom policies cannot be created for the same event as an existing system default — use the toggle and severity controls on the existing system entry instead.

***

## Supported alert events

Alert policies can be configured for any of the following 40+ audit events. System defaults are marked with ★.

### Authentication

| Event              | Recommended Severity |
| ------------------ | -------------------- |
| User Signed In     | Low                  |
| User Signed Out    | Low                  |
| Account Locked Out | High                 |

### Files — My Files

| Event                  | Recommended Severity |
| ---------------------- | -------------------- |
| File Uploaded          | Low                  |
| File Viewed            | Low                  |
| File Deleted           | High                 |
| File Shared            | Medium               |
| Shared File Downloaded | Medium               |
| File Version Created   | Low                  |
| File Version Restored  | Medium               |

### Files — Secure Rooms

| Event                        | Recommended Severity |
| ---------------------------- | -------------------- |
| File Uploaded to Secure Room | Low                  |

<Tip>
  Room file uploads are tracked separately from My Files uploads. This lets you create distinct alert thresholds for sensitive room content without affecting alerts for personal file activity.
</Tip>

### Secure Rooms

| Event                    | Recommended Severity |
| ------------------------ | -------------------- |
| Room Created             | Low                  |
| Room Archived            | Medium               |
| Room Restored            | Low                  |
| Room Deleted ★           | Critical             |
| Room Member Added ★      | Low                  |
| Room Member Removed      | Medium               |
| Room Member Role Changed | Medium               |

### Users & Access

| Event                  | Recommended Severity |
| ---------------------- | -------------------- |
| User Invited ★         | Low                  |
| Invite Accepted        | Low                  |
| User Status Changed ★  | High                 |
| User Role Changed ★    | High                 |
| User Removed           | High                 |
| User Moved to Org Unit | Medium               |

### E-Signatures

| Event               | Recommended Severity |
| ------------------- | -------------------- |
| Signature Requested | Low                  |
| Signature Submitted | Low                  |
| Signature Declined  | Medium               |
| Signature Cancelled | Low                  |

### Approvals

| Event              | Recommended Severity |
| ------------------ | -------------------- |
| Approval Requested | Low                  |
| Approval Approved  | Low                  |
| Approval Rejected  | Medium               |
| Approval Cancelled | Low                  |

### Secrets

| Event           | Recommended Severity |
| --------------- | -------------------- |
| Secret Created  | Medium               |
| Secret Viewed ★ | Medium               |
| Secret Deleted  | High                 |

### DLP

| Event                  | Recommended Severity |
| ---------------------- | -------------------- |
| DLP File Quarantined ★ | Medium               |
| Anomaly Detected       | High                 |

### KMS

| Event                           | Recommended Severity |
| ------------------------------- | -------------------- |
| KMS Connection Deleted ★        | Critical             |
| KMS Encryption Policy Removed ★ | High                 |

### Storage

| Event                           | Recommended Severity |
| ------------------------------- | -------------------- |
| Storage Configuration Deleted ★ | Critical             |
| Storage Disabled ★              | High                 |

★ = System Default (pre-wired, cannot be deleted)

***

## Behavioral Anomaly Detection

### How it works

The anomaly engine evaluates every file-access event against a set of configurable detection rules. It checks access counts, timestamps, geolocation, and device fingerprints — and creates an alert if a rule threshold is crossed.

Anomaly alerts are scoped to the room (or `My Files` for personal uploads) and include the file name, actor, severity, and structured detail about what triggered the rule.

### Detection rules

Five rules are enabled by default. All thresholds and time windows are configurable at **Security → Alert Policies → Rules**.

| Rule                 | What it detects                                                | Default threshold | Classification gate | Severity | Cooldown |
| -------------------- | -------------------------------------------------------------- | ----------------- | ------------------- | -------- | -------- |
| **Bulk access**      | Distinct files accessed by one user in a short window          | 5 files / 5 min   | Any                 | High     | 1 hour   |
| **Repeated access**  | Same file accessed many times in a short window                | 3 times / 5 min   | C3 or above         | High     | 1 hour   |
| **New country**      | File accessed from a country not previously seen for this user | 1 access          | C2 or above         | Critical | 1 hour   |
| **Off-hours access** | File accessed outside 08:00–20:00 UTC                          | 1 access          | C3 or above         | Medium   | 2 hours  |
| **New device**       | File accessed from an unrecognised browser or device           | 1 access          | C2 or above         | Medium   | 24 hours |

<Note>
  Classification gates mean a rule only fires when the file's clearance level meets or exceeds the minimum. For example, the "Repeated access" rule ignores unclassified and C1/C2 files by default — only C3 and C4 files trigger it.
</Note>

### My Files coverage

Anomaly detection applies to files accessed outside Secure Rooms, including My Files and files accessed via shared links. These alerts use `My Files` as the room label. Notifications fall back to the tenant's alert email list when no room context is available.

### Tuning a rule

Go to **Security → Alert Policies → Rules** and click the rule you want to adjust. You can change the threshold count, time window, cooldown period, and minimum classification level without disabling the rule. Toggle the rule off to suspend it entirely.

***

## Alert dashboard

All alerts — both policy alerts and anomaly alerts — appear in **Security → Alerts**.

Each alert entry shows:

* **Severity** — Critical / High / Medium / Low
* **Type** — policy alert name or anomaly rule
* **Actor** — user who triggered the event
* **Resource** — file or room involved
* **Time** — UTC timestamp
* **Detail** — structured breakdown of what triggered the alert (access counts, country, device, etc.)

Alerts can be filtered by severity, type, date range, and actor.

### File lock

For anomaly alerts involving a specific file, admins can **lock the file** directly from the alert entry. A locked file is suspended from further access while the incident is investigated. Access resumes when the admin manually unlocks the file or the lock window expires.

***

## Notifications

When an alert fires, Enclave notifies **all active Owners and Security Officers** in the tenant:

* **In-app** — notification bell with alert title and brief summary
* **Email** — formatted message with full detail, actor information, and a direct link to the alert
* **Slack** (if configured) — message to the configured webhook with severity indicator and context

Notification settings — including the Slack webhook URL and a configurable email override list — are managed at **Security → Alert Policies → Settings**.

***

## Alert severity levels

| Severity     | Typical use                                                                                   |
| ------------ | --------------------------------------------------------------------------------------------- |
| **Critical** | Irreversible or destructive actions — KMS deletion, storage deletion, new-country file access |
| **High**     | Privilege escalation, bulk access, repeated access to sensitive files, account suspension     |
| **Medium**   | Off-hours activity, new device, DLP quarantine, secret access, signature declined             |
| **Low**      | Informational events — sign-in, user invited, member added — disabled by default              |

***

## Compliance mapping

The alert categories and system defaults are designed to address common requirements across major compliance frameworks:

| Framework          | Relevant coverage                                                       |
| ------------------ | ----------------------------------------------------------------------- |
| **SOC 2 Type II**  | User role changes, KMS events, access anomalies, DLP quarantine         |
| **ISO 27001**      | Privileged access monitoring, incident detection, key management events |
| **GDPR / UK GDPR** | File access patterns, sharing events, user status changes               |
| **HIPAA**          | Off-hours access, new-device alerts, bulk access detection              |

Refer to the [Compliance](/enclave/compliance) page for a full framework mapping.