Aurva

Data at Rest Policies

Create rules to detect risks in stored data assets — misconfigurations, unencrypted data, public exposure, and more.

Data at Rest policies evaluate the configuration and classification state of your stored data assets. They do not require activity monitoring to be enabled.

Example use cases:

  • PII data in S3 buckets that are publicly accessible
  • Sensitive databases without encryption enabled
  • Assets with versioning disabled

Creating a Policy

Navigate to Configurations → Policies or DAM → Custom Policies, then click New Policy and select Data at Rest.

The wizard has five steps:

  1. 1

    Basic Details

    Enter a policy name, description, and severity. Assign a compliance framework tag (PCI-DSS, HIPAA, GDPR, SOC 2) and add impact and remediation guidance.

    Use a clear naming convention: "Privacy — S3 — Public Access" is better than "Policy 1". Your on-call team will thank you at 3am.

  2. 2

    Select Data Assets

    Choose the scope: IN (apply to selected assets) or NOT IN (exclude selected assets). Target All assets, individual assets, or dynamic Groups.

    Use Groups when you want the policy to automatically include future matching assets.

  3. 3

    Apply Conditions

    Build the condition logic. Choose Match All (AND) or Match Any (OR), then add conditions:

    FieldExample
    Publicly Accessibleis true
    Encrypted Statusis false
    Versioning Statusis disabled
    Sensitive Data Typeincludes PII

    You can use preset condition groups or build custom ones.

  4. 4

    Configure Actions (Optional)

    Route alerts to one or more destinations:

    SeverityRecommended Route
    criticalOn-call channel + P1 Jira ticket
    high#sec-ops Slack + P2 Jira ticket
    medium#sec-ops Slack + P3 Jira ticket
    lowDaily digest email
  5. 5

    Preview & Create

    Review the scope, conditions, and routing. Aurva runs a pre-save validation checklist. Click Create — the policy goes live immediately and can be enabled/disabled at any time.

Best Practices

Keep one risk per policy. Combining "public + unencrypted + no versioning" into a single policy makes remediation harder — you can't assign different owners or SLAs to each condition.

  • Start with Individual asset scope in a sandbox environment, validate results, then expand to Groups
  • Write the Remediation field with enough detail that any engineer can act without additional context
  • Enable auto-scan on assets covered by high-severity policies so findings stay current