Skip to content

Control status derived from findings, not from a spreadsheet

A control that is green because someone ticked it tells you nothing. These controls are green because the account was scanned and no finding matching them is currently open — which is a real statement, and a narrower one than a compliance report.

cloud compliance mappingsoc 2 cloud controlscontinuous compliance monitoring

The problem

Compliance status in most organisations is a document that was true on the day it was written. The controls are real, the evidence was real, and the gap between the document and the running infrastructure grows every day after the audit — invisibly, because nothing re-checks it until the next cycle.

A security scanner already knows a lot of what those controls assert. Whether encryption is on, whether logging is enabled, whether public access is blocked, whether privileged identities are accumulating. The useful move is to score the control from that data continuously, and to be exact about which part of the control the data can actually speak to.

How a control gets its status

Each mapped control names a class of finding — a signal type and the kind of resource it applies to. The engine counts the findings of that class that are currently open for the tenant and scores the control from the count: none is compliant, a few is partial, many is non-compliant. Findings expire on their own schedule, so a control recovers when the underlying issue stops being reported rather than when someone closes a ticket.

Re-evaluation is scheduled, not event-driven: hourly on Enterprise, every six hours on Growth, daily on Starter, with an on-demand run when you trigger a scan or connect an integration. Each run writes the status, the counts behind it and a timestamp, and compares against the previous snapshot to emit drift when something regresses.

What you get out

  • Per-framework posture — each mapped control with its status, the finding counts behind it, and when it was last evaluated.
  • A JSON or PDF summary per framework, with one line per control and a generated narrative sentence. Useful for an internal review or to send ahead of a questionnaire; it is a summary of status, not an evidence pack.
  • Draft questionnaire answers for SIG Lite, ISO and CAIQ, derived from live findings — a starting draft that a human corrects before it goes anywhere.
  • Drift signals when a control stops passing, on the same bus as every other finding, so a compliance regression can correlate with the security event that caused it.
  • A tamper-evident request log — hash-chained per tenant with an append-only database trigger, which is the one integrity guarantee on this page that is genuinely strong.

What this is not

This is cloud-findings-derived control mapping. It is not an audit, and it does not produce an auditor's evidence package. The distinction matters commercially, so here it is in full.

  • Not framework coverage. Thirty controls across six frameworks, selected because scan data can speak to them. SOC 2 is four controls, not the CC series. Say "maps to", never "compliant with".
  • Not a SOC 2 Type II anything. Type II is operating effectiveness across a period, assessed by an auditor. Nothing here evaluates a period, samples a population, or carries an opinion.
  • No non-cloud controls at all. Personnel and HR, policy documents, security training, vendor management, risk registers, incident response procedures, business continuity testing, management review — none of it. There is no policy upload, no attestation, no control owner and no due date. If you need those, you need a compliance platform; this is the cloud half.
  • Evidence is counters and a snapshot, not primary artefacts. What is stored against a control is the status, the finding counts behind it, and a point-in-time snapshot. The artefacts are written to the worker's local disk, not to object storage, with no retention enforcement and no immutability — so treat them as working output, not as records.
  • Exports are unsigned. The JSON and PDF carry no hash and no signature, and the PDF is a plain text rendering of the summary.
  • Statuses can be overridden by hand, and the next scheduled run overwrites the override. The request log records that a change was made, not what it changed from or to.
  • No history. Each run replaces the previous status for a control. There is no time series, which is another reason this cannot answer a period question.
  • Two of the thirty controls are not scored from their own data. ISO 27001 A.9.4.2 has no automated check behind it and reports unknown; SOC 2 CC8.1 reports partial whatever its drift count says, because drift detection alone does not establish change control.

Where it fits

Use it to shorten the distance between a security finding and the control it breaks — so the people answering the questionnaire and the people fixing the bucket are looking at the same data, continuously, instead of reconciling two documents once a year. Then keep your audit evidence where your auditor expects it. Those are different jobs, and a tool that claims both tends to do the second one badly.

Can we use this to get SOC 2 certified?
No, and nothing that works this way can. Certification requires an auditor to examine evidence and form an opinion, including over controls no cloud scanner can see — hiring, training, vendor management, incident response practice. What this does is keep the cloud-visible controls continuously scored, which reduces how much of an audit is spent discovering that infrastructure drifted after the last one.
Why do you publish the limits this bluntly?
Because the alternative gets found out in a procurement review, and because a control status that is trusted more than it deserves is worse than no status. The trap this avoids by design is absence of data reading as compliance — an unscanned account reports unknown, not green. The remaining limits are the ones listed above, and they are structural rather than oversights.
Does it cover anything outside AWS?
The control mappings score whatever findings exist, so any provider the engines cover contributes. The mappings themselves were written against cloud-style resource classes — storage, identity, logging, encryption, networking — so coverage follows the scanners rather than the framework.
What happens to a control when we stop scanning?
Its findings expire, and once there is no current scan evidence at all the control reports unknown with that reason recorded against it. A stale green is the one failure mode a continuously-scored control cannot be allowed to have, so it reports nothing rather than something reassuring.

Run it in your own account

One Docker Compose stack, your datastores, read-only credentials into your clouds. The Community edition is free to run in production.