Skip to content

Compliance

Compliance turns your scan results into a posture you can defend to an auditor. It has two tabs, and they map to two different jobs: Framework Overview for reporting upward, and Control Management for investigating a specific control and planning the work that closes the gap.

Nothing here is configured by hand. Compliance is evaluated automatically whenever a datastore is scanned, so the page reflects your last scan rather than a questionnaire you filled in. How controls are mapped and how readiness is decided is in Compliance mapping & readiness.

Present on every tab.

Tile What it means
Frameworks Blocked Frameworks with a failing in-scope control, with how many are Incomplete and Ready for review beside it
Frameworks In Scope Frameworks your data or identities fall under, of all the frameworks you report on
Scanned Datastores The evidence base behind every other number
Total Violations Failing controls across all frameworks

There is no overall percentage. Each framework carries its own readiness, and a framework whose evidence Argus could not fully read is Incomplete rather than ready, however many of its automated controls pass. Readiness is Argus’s view of the controls it can check automatically, not a certification or an auditor’s opinion; the page says so under the row.

This is the single most important thing to understand about the page, and it appears everywhere on it.

A control reads Not verified when Argus could not check the evidence to judge it, and the reason names why: most often a read permission the agent’s IAM role is missing, sometimes an identity input it could not collect. It is not a pass and not a fail: it is a blind spot, and it keeps the framework Incomplete for a reason that is fixable in minutes.

When posture verification is blocked, a banner appears under the tabs naming how many datastores are affected and, where it can, the exact permissions to grant. It is not dismissible by design, though you can collapse it to one line. It clears itself when the underlying block is fixed. The fix is IAM permissions, not anything about your data. A datastore with no read of its contents on record is listed once in an Applicability unknown notice instead, and counted under no control. A datastore Argus read before but could not read on the latest scan keeps the results of its last successful read; its drawer says the latest read failed and names the date of the last one. Once that read is past your evidence age limit, its Passing and Partly met controls read Not verified and a Failing control stays Failing, showing the last read date.

Six statuses exist across the page. Each explains itself on hover, and the Control Management tab carries a legend:

Status Meaning What to do
Passing Every datastore and identity the control applies to meets it. Passing (partial evidence): each meets it, and part of the control rests on evidence Argus cannot collect Nothing
Failing At least one datastore or identity fails it Remediate the resource
Partly met Met as far as Argus can see; part of it rests on evidence Argus cannot collect, or a gap the control treats as recommended Read the “not assessed” line
Not verified Argus could not check a signal it needed Act on the reason, usually a permission grant
Not applicable Out of scope for your estate Nothing
Manual Procedural or physical. No signal can decide it Handle it outside Argus

The last two are easy to confuse and mean opposite things. Not verified is a blind spot Argus should be able to see through - a permission grant fixes it, and it drags Coverage down until you do. Manual (internally not_assessable) is something Argus can never see, like a breach-notification deadline or a physical facility control. No permission would help, so it is excluded from both the automated-controls count and Coverage. It counts neither for nor against you.

About half the control set is manual attestation. That is a property of the regulations, not a gap in Argus - see Compliance mapping & readiness for the per-framework breakdown.

The reporting view. Three charts across the top:

  • Violations by Framework - where your failures concentrate.
  • Top Violations - the most common failing categories, so you can spot one root cause behind many controls.
  • Severity Breakdown - critical, high, medium, low across everything.

Below them, Framework Compliance: one card per framework with its readiness (Blocked, Incomplete or Ready for review), “N of M automated controls passing”, one line saying what the readiness means, the reasons behind it worst first, and a control breakdown of Failing, Partly met, Not verified and Passing, worst first, and manual-attestation counts. Each card states its coverage in words, for example “18 of 25 controls automatically assessed, 13 need manual attestation”. Cards also show a violation count split by severity and an estimated exposure figure. Hover a card’s readiness for how that framework’s reasons are ordered (its reporting mode).

Read the reasons rather than the count. A framework at 18 of 25 with a list of unread datastores is not seven controls broken, it is largely unmeasured, and the work to fix it is a permission change rather than a remediation project.

An unassessed control never hides behind a pass. A framework whose automated controls all pass is still Incomplete while any datastore it governs is unread, unscanned or held from an earlier read, and each one is listed. A framework you excluded in Settings > Security is gone from this page; a link to it says it is excluded.

The investigation view: every control, individually.

Pick All Frameworks or one framework from the selector, then search across control references, titles, descriptions, and framework names. Filters cover Category (Data Security, Privacy, Access Control, Encryption, Breach Notification, Data Integrity), Severity, and Status, plus Framework when you are viewing all of them.

Two view modes, toggled at the right of the toolbar:

  • Table - Ref, Control (title with its description beneath), Severity, Status, Category, and Affected: how many of the subjects it applies to pass, for example “3 of 5 passing”. Sorted by status by default so the worst sits at the top, and every sort falls back to severity, so ties never order arbitrarily.
  • Matrix - a compact grid for scanning many controls at once.

The Status filter covers every status the backend can emit, including Not verified and Manual, so blind spots and procedural controls are both reachable from here.

Clicking any control opens it.

Overview carries the control name, framework, reference, category, severity, status, the count of affected datastores, the full description, and the data types affected, which is what connects an abstract control to the actual sensitive data that triggered it.

Affected Subjects opens with how many of them pass, for example “3 of 5 datastores passing”, then lists every datastore and identity that needs work, each with its own result: Failing, Partly met, Not verified with its cause, Passing (partial evidence), or a result held from the date of the last successful read. Under each one, a checklist shows every recommendation for that subject: Met, Not met, Not verified with what Argus could not read, or Not applicable to that kind of subject. Each links straight to its own drawer. This is the fastest path from “we fail this control” to “here are the eleven buckets to fix, and what each one is missing”.

A datastore or identity that discovery no longer finds leaves every control, and the compliance report, at once: it is not listed, counted or attached to a recommendation there. Its own drawer still shows the last details Argus had before it went missing.

Associated Alerts lists the alerts raised from the same underlying condition, so you can see whether the control failure is already being worked.

Evidence is why Argus reached this verdict: a plain sentence, then the signals it consulted with the value observed, the API call each came from, and when. If the control could only be partly assessed, this section names exactly which facets were out of reach, so a partial verdict can never be read as a complete one. For a manual-attestation control this section replaces the status entirely, stating what would satisfy the control instead.

Recommendations surfaces the suggested fixes for the control. Each one says how many subjects it still affects: the subjects that still fail the control with that fix open, never resolved or dismissed history. A subject failing on more than one count, for example a bucket both public and unencrypted, is listed under each fix that applies. See Recommendations.

There is no export button on this page. Compliance exports live under Reports, which produces the compliance report (each framework’s readiness, automated controls passing and reasons, plus failing controls with citations, statuses, severities, subjects passing, and affected datastores), the manual-attestation list (every control Argus cannot assess, with the reason, ready to import into a GRC tool), and the executive summary.

Two guarantees hold for audit integrity: exports carry counts and metadata only, never the sensitive values themselves, and they exclude hidden and stale datastores while surfacing the count of what was excluded, so posture cannot be quietly improved by hiding a bad asset.

  1. Start on Framework Overview and pick a Blocked framework, or an Incomplete one if none is blocked.
  2. Check its Not verified count first. If it is significant, fix the permission and re-scan before doing anything else, because the rest of the numbers will move. If the role comes from the Argus stack, update the stack (see Updating permissions).
  3. Move to Control Management, filter that framework to Failing, and work down by severity. Criticals first, then partials.
  4. Open a control’s Evidence section when you need to answer an auditor’s question about it, or to see which facets of a partial control were out of reach.
  5. Export the manual-attestation list once and route it to whoever owns policy and process. That half of the control set is not going to resolve itself from the Argus side.