Policies
Policies are your own rules, in addition to the compliance frameworks Argus ships with. Compliance answers “does this meet GDPR”; a policy answers “does this meet our standard”, for example no PII outside production, or nothing unencrypted holding financial data.
The page has two tabs: Policies, the library you author, and Violations, the findings those rules produce. The sidebar reaches both, listing Policies under Govern and Violations under Detect, because writing rules and triaging findings are different jobs done by different people. They are the same page on different tabs.
Tab 1: Policies
Section titled “Tab 1: Policies”The library. Five counters across the top: Active Policies, Open Violations, Compliance, Response Rate, and Needs Review.
Each row carries the policy name, severity, status, category, scope, and then the columns that tell you whether the rule is any good: Open violations, In Scope resource count, Compliant percentage, Response rate, Last Evaluated, Owner, and Review status.
Read In Scope next to Open. A policy matching zero resources is not passing, it is not doing anything, and that is the most common failure mode for a hand-written rule. Filters cover Category and Status.
Statuses
Section titled “Statuses”| Status | What it does |
|---|---|
| Draft | Not evaluated. A work in progress |
| Simulating | Evaluated, and it reports what it would flag, without creating real violations |
| Active | Evaluated, and it creates violations |
| Disabled | Turned off. Set by the Enable/Disable action rather than by editing |
Simulating is the one to use. It lets you see a rule’s true blast radius against your real estate before it starts generating work for your team. A broad rule promoted straight to Active can bury the Violations tab in hundreds of findings, and the fastest way to get a policy ignored is to ship it noisy.
Creating a policy
Section titled “Creating a policy”New Policy offers a blank policy or a starter template. Either way you land in the builder with a draft, so nothing is enforced until you deliberately promote it.
The builder has four sections:
Summary - name, category (Classification, Access Control, Retention, DLP, Encryption, Residency, Other), description, status, the violation severity this policy raises, an owner (a user or a team, defaulting to you), a review reminder interval, and escalation days after which open violations are escalated.
Set the owner and the review interval even though both are optional. An unowned policy nobody revisits is how a library rots into rules that no longer match how the business runs, which is what the Needs Review column exists to catch.
Scope - which resources the policy applies to, by cloud account, region, or specific datastores. Hidden and not-found datastores are not offered as targets, since they are excluded from evaluation anyway.
Rules - the conditions. Fields available are the ones Argus actually knows about a datastore:
| Field | Type |
|---|---|
| Is Public, Is Encrypted, Encryption Enabled, Has Sensitive Data | true or false |
| Risk Score, Size | numeric comparison |
| Risk Level, Datastore Type | one of a fixed set |
| Region | text match |
| Last Scanned At | date comparison |
| PII, PHI, Financial, and Credential finding counts | numeric comparison |
Operators vary by field type: booleans compare equal or not equal, numbers and dates take greater or less than, text supports contains and in-list, and most scalars also support exists and does not exist.
Evaluation & Impact - the part worth using before you save. It previews how many datastores are in scope and how many would violate the rule as written. That is your noise check: if a rule you intended for a handful of stores previews 400 violations, the rule is wrong, not your estate.
The read-only policy drawer adds Open Violations, Reviews, and Change History, so you can see who changed a rule and when, which matters when a violation count moves and nobody knows why.
Tab 2: Violations
Section titled “Tab 2: Violations”Findings, one per resource per broken rule. Five counters: Open, Escalated, In Progress, Waived, and Resolved (7d).
| Column | Notes |
|---|---|
| Policy | Which rule was broken |
| Severity | Inherited from the policy |
| Status | The lifecycle state below |
| Category | |
| Source | The datastore, with its lifecycle status badge, linking to its drawer |
| Age | Days open, badged green under a week, amber under two, red beyond. Only badged while live |
| Detected | When it first appeared |
| Assignee | The user or team working it |
Filters cover Status, Severity, and Aging (7+, 14+, or 30+ days). Aging is a single threshold rather than a multi-select, because it is a cutoff, not a set.
Age is the column to sort by once volume is under control. Severity tells you what matters; age tells you what is being quietly ignored.
The violation lifecycle
Section titled “The violation lifecycle”Five states, and the available actions depend strictly on the current one.
| Status | Meaning | Actions available |
|---|---|---|
| Open | Detected, nobody has picked it up | Take Over, Waive, Resolve, Assign |
| In Progress | A person is working it rather than the system | Waive, Resolve, Assign |
| Waived | Accepted as a known finding and muted | Lift Waiver only |
| Resolved | Cleared | None. Terminal |
| Dismissed | Closed by the system, for example the datastore was deleted | None. Terminal |
What each action does
Section titled “What each action does”Take Over moves an open violation to In Progress. It means “a human owns this now”, nothing more. It does not mute anything and does not accept the risk.
Resolve requires a resolution note answering what changed. And it is not a mute:
Waive accepts and mutes a known finding. It requires a reason and takes an expiry: 30, 60, 90, or 180 days, or permanent. Prefer a dated waiver. A waiver that expires comes back for review on its own, which is the difference between an accepted risk and a forgotten one.
Lift Waiver returns a waived violation to In Progress, and it is the only action available on a waived violation. This is deliberate: it means a mixed selection of open and waived violations has no action in common, so a bulk Take Over can never silently un-waive something you had consciously accepted.
Assign hands it to a user or a team. Only available while the violation is live; assignment is frozen on waived, resolved, and dismissed violations.
All of these are available from the row menu, from a bulk selection, and from the drawer footer, and all three read from the same rule set, so what you can do never depends on where you clicked.
The violation detail drawer
Section titled “The violation detail drawer”Summary carries the finding and its state. Source links to the offending datastore. Policy links to the rule that produced it. Related Alert appears where the same condition also raised an alert, so you are not working the same problem twice in two places. Assignment holds ownership.
How violations relate to alerts and compliance
Section titled “How violations relate to alerts and compliance”Three things can fire on one underlying condition, and they are not duplicates:
- A compliance control fails, because a framework requires it. See Compliance.
- A policy violation opens, because you required it.
- An alert may be raised, because it needs attention now. See Alerts & Incidents.
The drawers cross-link, so you can see the whole picture from any one of them. The vocabulary differs by design, though: violations are waived, alerts are suppressed. They are different mechanisms on different objects, and the actions are not interchangeable.
Violations also follow the datastore lifecycle. When a datastore disappears from your cloud and its grace window passes, its open violations are dismissed automatically rather than left open against something that no longer exists, and if it reappears they reactivate. Hiding a datastore suppresses its violations too. Both behaviours are covered in Discovery & scanning and Datastores.
A workflow that works
Section titled “A workflow that works”- Author the rule as a draft, and set an owner and a review interval.
- Use the Evaluation & Impact preview to check the in-scope and would-violate counts.
- Promote to Simulating and leave it for a scan cycle. Confirm it flags what you meant.
- Promote to Active.
- Triage the Violations tab by severity, then by age. Take Over what you will work, Waive with an expiry what you are accepting, and Resolve with a note only what you actually fixed.