Compliance mapping & readiness

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 reports each framework’s readiness and how many of its automated controls pass. Every result 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 counted. 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	8	1
PCI DSS	10 of 21	10	0
GDPR	8 of 21	7	1
HIPAA	8 of 19	8	0
SOX	6 of 11	6	0
SOC 2	5 of 9	5	0
GLBA	4 of 8	4	0
CCPA	2 of 6	2	0

Across all eight: 52 of 107 controls are assessed automatically, 55 require manual attestation.

These ratios are published deliberately. ISO 27001 and SOC 2 rank highest because they are technical-control frameworks. GDPR and CCPA rank 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: a framework’s “N of M automated controls passing”, 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	Counted?
Automated	Every signal the control needs is collected.	Yes
Partial	Some facets are observable, some are not.	Yes, and a pass says it rests on partial evidence
Not assessable	Procedural, organizational or physical. No signal decides it.	Never

A partial control can never be reported as a full pass. GDPR Art. 44 governs cross-border transfers; Argus reads where the data lives, but not the transfer safeguard (adequacy decision or standard contractual clauses) that makes a transfer lawful. When everything observable passes, such a control reports Partly met and names what was not assessed. Claiming a clean pass there would be asserting something we did not check.

The same cap applies per resource. Transmission security, key management and access logging are read by the Argus agent from version 1.1.0; a resource whose agent has not yet reported one of them reports Partly met on the controls that need it, naming the signal as not collected, rather than passing on evidence nobody read.

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 Failing 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 reads Not applicable, not counted against you. A datastore with no read of its contents on record is neither: it is listed once as Applicability unknown and counted under no control. A datastore Argus read before but could not read on the latest scan keeps the result its last successful read decided, and says that the latest read failed and when the last one succeeded, until that read is past your evidence age limit; after that its Passing and Partly met results read Not verified, a Failing result stays Failing with its last read date, and what that read found absent is no longer assumed absent. The age is counted from the last successful read, not the last scan attempt: a scan that could not read the datastore does not reset it. The compliance page lists a datastore past that limit whose last read found data types as partly unassessed: controls for data types that read did not see cannot be decided. A scan that reads part of a datastore and is denied (or fails) on the rest counts as a read: its results come from what it read, and the datastore and its controls say it was not fully read, why, and how much.

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

Status	Meaning	In N of M	In coverage
Passing	Every subject this control applies to was observed and meets it.	N and M	Yes
Failing	A confirmed failure on at least one subject.	M	Yes
Partly met	Met as far as Argus can see; part of it rests on evidence Argus cannot collect (counted passing, and says so), or on a gap the control treats as recommended rather than mandatory (counted failing).	N and M, or M	Yes
Not verified	Argus could not check a signal it needed, and says why: a denied posture read, content whose last read is past your evidence age limit, an identity input it could not collect.	M, never N	Counts against
Not applicable	The subject holds none of the data this control governs.	No	No
Manual	Procedural or physical. No signal decides it; it needs evidence you provide.	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, and the reason names what to fix, most often a read permission to grant. It drags Coverage down until you do.
• Manual - 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. A stored card number alone does not fail it.

When a control spans many subjects, the worst result wins - Failing, then Partly met, then Not verified, then Passing - so one exposed bucket is never averaged away by a hundred healthy ones, and one passing bucket never vouches for another Argus could not check.

How readiness is decided

Each framework shows two things, and never a percentage:

• {N} of {M} automated controls passing. M counts the controls Argus can check (Automated and Partial) that apply to at least one of your datastores or identities. N counts those passing on every subject they apply to, on current evidence: a verdict held from an earlier read is not counted passing.
• A readiness, decided by one rule for every framework:

Readiness	When
Blocked	Any in-scope control is Failing or Partly met on a confirmed gap.
Incomplete	Nothing fails, but Argus could not check everything: a datastore it could not read or has not scanned yet, a control it could not verify, a verdict held from an earlier read. Each gap is listed with its cause.
Ready for review	Every automated control Argus checks passes on current evidence. Manual controls still need your evidence.

Readiness is Argus’s view of the controls it can check automatically. It is not a certification or an auditor’s opinion, and no surface says you are compliant with a framework.

Reporting modes

The rule is the same in every mode. The mode decides how the reasons are ordered, the way an assessor reads that framework:

Mode	Frameworks	How the reasons read
Binary	PCI DSS	Each requirement is in place or not. One failing in-scope control blocks the framework.
Attestation	ISO 27001, SOC 2, SOX	An auditor forms an opinion over exceptions. Failing controls are listed as exceptions, worst severity first.
Risk with required elements	GLBA, HIPAA	Required elements are listed first; addressable ones follow. Any failing in-scope control still blocks.
Risk	CCPA, GDPR	Measures must be appropriate to the risk. Failing controls are listed worst severity first.

A framework never presents as ready on nothing. One Argus could not check reads Incomplete, with each gap listed. One with nothing to evaluate has no readiness: Not applicable when none of its data types were found, Nothing Argus can check here yet when it applies but no automated control has anything in scope yet. Neither reads Ready for review.

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

Coverage and readiness close the gaming route together: revoke Argus’s read permissions and the controls it can no longer check never count as passing, every one of them makes the framework Incomplete, and Coverage drops. A framework is never Ready for review over evidence Argus could not read. If coverage is low, the fix is granting the missing permission - see IAM permissions.

Excluding a framework

All eight frameworks are on by default. An admin can exclude one in Settings > Security > Compliance frameworks; it then disappears from the compliance page, reports, exports and the assistant. Findings, alerts, recommendations and risk scores are not affected, and including it again is instant: Argus keeps evaluating it.

Why a datastore or identity has no readiness

Open a datastore or an identity and you will see which controls it breaks, and how many of its automated controls pass, never a readiness and never a percentage.

That is deliberate. There is no such thing as being 78% of the way to GDPR. Readiness is control-first (the worst result across every subject wins per control), so it is decided per framework over every subject at once, and a single resource cannot be ready or blocked on its own.

Readiness therefore lives in exactly one place: per framework. A resource’s answer is the list of controls it breaks, each control’s checklist of what that resource meets, 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 readiness covering data and identity posture together. Identity detail is still available per principal, but it does not produce a second, parallel count to reconcile against the first. An identity input Argus has never collected, such as console access, MFA devices or Access Advisor usage, reads Not verified on the controls that need it, never a pass or not applicable. One collected before and missed on the latest scan keeps its last value, and its controls keep their results with a note naming the input and the date it was last read, until that read is past your evidence age limit; then Passing and Partly met read Not verified and a Failing result stays Failing.

Each subject is judged on its own signals. A datastore’s result for one of these controls rests on the datastore’s signals and says that the identity side is assessed on your IAM identities; an identity’s result rests on the identity’s signals and says the same of the data side. A requirement with nothing to read on a datastore is not evaluated on one: GLBA’s multi-factor authentication control (16 CFR 314.4(c)(5)) is evaluated on your identities only, and with no human IAM user it reads Not applicable, never Passing.

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:

Failing - 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 - each framework’s readiness, automated controls passing, reasons and coverage, and the full list of failing controls with citations, statuses, severities, how many subjects pass each, and affected datastores. Every export carries the readiness disclaimer, and a datastore Argus did not fully read says so.
• 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 a Blocked framework, open its failing controls, and work top-down by severity - Failing criticals first, then Partly met. 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 Manual attestation list and route it to whoever owns policy and process. The page-by-page workflow lives in Compliance.