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

# Custom cloud rules

> Write your own CSPM checks and run them against your cloud assets

**Cloud → Settings → Custom Rules** is where you define your own cloud security checks. An enabled rule runs during every CSPM scan, and each asset it matches becomes a finding.

Custom rules sit alongside the standard checks Heimdall already runs. Use them for the policies specific to your organisation, such as a tagging standard or an encryption requirement.

## The rules table

| Column         | Description                                   |
| -------------- | --------------------------------------------- |
| **Name**       | What the rule checks                          |
| **Severity**   | Critical, High, Medium, or Low                |
| **Category**   | Your own grouping label, such as `encryption` |
| **Conditions** | How many conditions the rule combines         |
| **Scope**      | Which assets the rule applies to              |
| **Enabled**    | A switch to turn the rule on or off           |

The actions menu on each row lets you edit, test, or delete a rule. Turning a rule off keeps it for later without running it.

## Starting from a template

**Browse templates** opens a gallery of ready-made checks for common misconfigurations, including unencrypted S3 buckets, security groups open to `0.0.0.0/0` on port 22, resources missing an `Environment` tag, IAM users with console access but no MFA, and publicly accessible databases.

**Use template** creates a normal custom rule from the definition, which you can then edit like any other.

## Writing a rule

**New rule** opens the rule builder.

### Details

Name the rule after what it enforces. `All S3 buckets must have encryption enabled` reads better in a finding than `S3 rule 1`. Add a description, a severity, and a category of your choosing.

### Conditions

Each condition tests one field on an asset. The field is a dot-path into the asset record, so `metadata.encryption.enabled` reads the encryption block Heimdall captured and `tags.Environment` reads a tag. You can see the fields available on any asset under **Metadata** on its [detail page](/platform/cloud/assets#asset-details).

The operators are **equals**, **not equals**, **contains**, **greater than**, **less than**, **exists**, and **does not exist**. The last two take no value.

<Info>
  Conditions are combined with AND. Every condition has to hold for an asset to match. To express an OR, write one rule per branch.
</Info>

### Scope

Scope limits which assets the rule is evaluated against. Leave a field empty to place no limit on it:

* **Providers**: AWS, Azure, or Google Cloud
* **Resource types**: specific types such as S3 buckets or EC2 instances
* **Regions**: a list of regions
* **Accounts**: specific connected accounts
* **Tag filters**: key and value pairs, using the same equals, not equals, exists, and does not exist operators

### Remediation

**Guidance** explains how to fix a violation and **Reference URL** links to supporting documentation. Both appear on the findings the rule raises, so whoever picks one up knows what to do.

## Testing a rule

**Test** on any rule dry-runs it against your current assets. The result reports how many assets matched out of how many were in scope, and previews the first of them with their name, type, provider, and region.

A test writes nothing and creates no findings, so it is the quickest way to check that a condition path is right before you switch a rule on.