Compliance mapping & scoring

Argus does not ask you to fill in a questionnaire. It maps what the agent actually discovers in your cloud - sensitive data, encryption state, public exposure, and IAM posture - onto the specific controls of each framework, evaluates every control it can against your real environment, and rolls the results into a score. Every point of that score traces back to an observed signal, on a named resource, from a named API call, at a known time.

What Argus is, and is not

Argus reports automated control coverage. For each framework it tells you which controls it can decide from cloud telemetry, what those controls currently say, and - just as importantly - which controls it cannot decide and why.

It is not a compliance-attestation platform. Tools in that category (Vanta, Drata, Secureframe) also track procedural controls: policy documents, security training, pen-test schedules, vendor reviews. Those are satisfied by a human attesting with evidence, and Argus does not track them.

That distinction is the single most important thing on this page, because it decides what a number here means:

• Argus can tell you whether the data a control governs is exposed, encrypted, logged, backed up, or reachable by over-privileged identities.
• Argus cannot tell you whether you notified a supervisory authority within 72 hours, whether your access-review process runs quarterly, or whether your data centre has badge readers.

Controls in the second group are surfaced with the reason they cannot be assessed, and are never scored. They count neither for nor against you.

Note

Mapping findings to a framework’s controls is not a certification. Argus tells you how your data posture lines up against SOC 2 or ISO 27001 requirements; it is not a claim that Argus, or your environment, holds an attestation.

Frameworks and coverage

Argus ships control mappings for eight frameworks. The “assessed automatically” column is how many of that framework’s controls Argus can decide from telemetry:

Framework	Assessed automatically	Fully	Partially
ISO 27001	9 of 12	6	3
PCI DSS	10 of 21	6	4
GDPR	8 of 21	7	1
HIPAA	8 of 19	5	3
SOX	6 of 11	5	1
SOC 2	5 of 9	3	2
GLBA	3 of 8	1	2
CCPA	2 of 6	2	0

Across all eight: 51 of 107 controls are assessed automatically, 56 require manual attestation.

These ratios are published deliberately. ISO 27001 and SOC 2 score highest because they are technical-control frameworks. GDPR and CCPA score lowest because they are largely rights-and-process statutes - a low number there is an accurate description of the regulation, not a shortfall in Argus. SOX is measured as ITGC over financial-reporting data (access, encryption, recoverability, segregation of duties, authentication, timely revocation) mapped to §404, because that is what a SOX audit actually tests; the statute sections themselves are reporting-process obligations.

Each control carries its real citation (GDPR Art. 5(1)(f), HIPAA §164.312(a)(1), PCI DSS Req. 3.4), so a finding always points at the exact clause it touches.

Verifiability: what Argus can decide

Every control declares which observable signals its verdict depends on. That declaration determines its class:

One word, one meaning: assessable

A control is assessable when Argus can decide it from telemetry - the Automated and Partial classes below. Not-assessable controls are excluded from every denominator on every surface: the framework percentage, Assessment Coverage, and the “breaks N of M assessable controls” line in a resource drawer all count the same set. Where you see “applicable” it means the narrower thing: assessable and actually in scope for the data this subject holds.

Class	Meaning	Scored?
Automated	Every signal the control needs is collected.	Yes
Partial	Some facets are observable, some are not.	Yes, but capped
Not assessable	Procedural, organizational or physical. No signal decides it.	Never

A partial control can never be reported as a full pass. HIPAA §164.312(e)(1) and PCI DSS Req. 4.1 both govern transmission security; Argus reads encryption at rest. When everything observable passes, such a control reports Partially Compliant and names what was not assessed. Claiming a clean pass there would be asserting something we did not check.

A Partial control can still fail outright

The cap applies to PASSING, never to failing. If a partial control’s visible facet fails - say a store holding cardholder data is confirmed unencrypted - it reports Non-Compliant at full severity weight, exactly like any other control.

That is intentional, and it is the asymmetry to expect: partial evidence is a reason to withhold a clean bill of health, never a reason to discount a confirmed problem. A failure you can see is real whether or not you could see everything else.

A not assessable control shows the reason it cannot be decided instead of a status badge, and states what would satisfy it. You can export the full list - see Manual attestation below.

Verifiability is derived, not declared

A control’s class is computed from the signals it needs versus the signals Argus collects. When a new collector ships, every control waiting on it is re-classified automatically, and a build-time check fails until each one has been reviewed. A control cannot drift into claiming evidence that does not exist.

How a finding becomes a control result

Every control declares the sensitive-data types it governs. A control only applies to a datastore that actually contains one of those types - a bucket of marketing copy is out of scope for a cardholder-data control and is scored Not Applicable, not counted against you.

When a control applies, Argus evaluates it against the signals it declared. The result is one of six statuses:

Status	Meaning	In score	In coverage
Compliant	Every signal the control depends on was observed and satisfied.	Yes	Yes
Non-Compliant	A confirmed failure.	Yes	Yes
Partially Compliant	A softer gap, or a partial control passing everything it can see.	Yes	Yes
Not Verified	Argus could not read a signal it needed (for example Access Denied).	No	Counts against
Not Applicable	The subject holds none of the data this control governs.	No	No
Not Assessable	Procedural or physical. No signal decides it.	No	No

The distinction between the last three matters:

• Not Applicable - the control does not govern anything you hold.
• Not Verified - Argus should be able to see this and could not. The fix is granting a read permission. It drags Coverage down until you do.
• Not Assessable - Argus can never see this. No permission would help. The fix is a human attestation. Folding it into Coverage would cap that metric permanently and make it meaningless, so it is excluded from both.

The directional logic is deliberately conservative. Confirmed public exposure fails every control that reads the data - encryption does not compensate for public reachability. An unverifiable posture is surfaced, never given the benefit of the doubt. And some data is prohibited outright: PCI DSS Req. 3.2 fails on the mere presence of stored authentication data, because encrypting a stored CVV does not make it permitted.

When a control spans many subjects, the worst result wins, so one exposed bucket is never averaged away by a hundred healthy ones.

How the score is computed

The score is a severity-weighted percentage, published in full because a compliance number you cannot reproduce is a number you cannot defend in an audit.

Each control contributes severity weight x status multiplier out of its full weight:

Severity	Weight		Status	Multiplier
Critical	10		Compliant	1.0
High	5		Partially Compliant	0.75
Medium	3		Non-Compliant	0
Low	1		Not Verified / Not Applicable / Not Assessable	excluded

score = sum(weight x multiplier) / sum(weight) x 100

A failed critical control moves the number far more than a failed low one: you cannot paper over a critical gap by passing a pile of trivial checks.

A framework with nothing evaluable reads “Not assessed”, never 100%. An empty or entirely unverified framework must never present as fully compliant.

Assessment Coverage

Coverage is the share of assessable, in-scope controls Argus could actually evaluate:

coverage = (passed + partial + failed) / (passed + partial + failed + not_verified) x 100

Excluding Not Verified from the score creates one theoretical gaming route: revoke Argus’s read permissions and the controls it can no longer check drop out, leaving a smaller, cleaner denominator. Coverage closes it.

A framework is never greener than its coverage allows. Below 90% coverage the score renders amber no matter how high it is; below 70% it renders grey and is marked provisional. A 100% score over 75% coverage is a real number, but it must not say “you are done” when a quarter of the assessable controls were never evaluated. If coverage is low, the fix is granting the missing permission - see IAM permissions.

Why a datastore or identity has no score

Open a datastore or an identity and you will see which controls it breaks, not a percentage.

That is deliberate. There is no such thing as being 78% compliant with GDPR. A percentage against a single resource was also a different measurement from the framework number - the framework score is control-first (worst status across every subject wins per control), so a per-resource share of its own controls could not be reconciled with it, and the two numbers invited the question of which one was real.

The percentage therefore lives in exactly one place: per framework, and the tenant rollup of frameworks. A resource’s answer is the list of controls it breaks and the evidence for each.

One control, one verdict

Some requirements are answered by both data posture and IAM posture. ISO 27001 A.5.15, SOC 2 CC6.1 and HIPAA §164.312(a)(1) all ask whether access is appropriately restricted - which depends both on whether the data is reachable and on whether identities hold more privilege than they use.

Each of these is one control evaluated over both subjects, worst result winning. A framework therefore has one number covering data and identity posture together. Identity detail is still available per principal, but it does not produce a second, parallel score to reconcile against the first.

Evidence

Every verdict carries its reasoning. Open a control and you see the signals consulted, the values observed, the API call each came from, the resource, and when it was observed:

Non-Compliant - this datastore is publicly reachable and holds email, ssn.

Signal	Observed	Source	When
content classification	email, ssn	agent content sampling	2 Aug 2026, 14:02
public exposure	Yes	s3:GetBucketPolicyStatus	2 Aug 2026, 14:02

Assessed: content classification, public exposure. Not assessed: none.

For a partial control, the “Not assessed” line names exactly which facets were out of reach, so a partial verdict can never be read as a complete one.

Manual attestation

The controls Argus cannot assess are exportable as CSV - framework, citation, title, severity, category, and the reason each is out of reach - sorted by framework and severity.

It imports directly into whatever GRC tool you already run. The intent is that Argus hands off the half of the control set it cannot decide, rather than listing it and stopping.

Export

Compliance results also export as CSV for auditors and your own records:

• Compliance report - overall score, per-framework scores and coverage, and the full list of failing controls with citations, statuses, severities, and affected datastores.
• Manual attestation list - the controls above.
• Executive summary - a one-page posture snapshot across data and alerts.

Two guarantees matter for audit integrity: exports contain counts and metadata only, never the sensitive values themselves, and they exclude hidden and stale datastores, so posture can never be quietly improved by hiding a bad asset - the count of excluded stores is surfaced, not swallowed.

Using it

Start with the lowest framework score, open its failing controls, and work top-down by severity - Non-Compliant criticals first, then partials. Treat Not Verified as its own work item: it usually means the agent’s IAM role is missing a read permission, and resolving it often turns a blind spot into a clean pass. The exact grants are listed in IAM permissions. Export the Not Assessable list and route it to whoever owns policy and process. The page-by-page workflow lives in Compliance.