From finding to evidence
A finding only becomes evidence when someone who did not run the assessment can pick it up, understand exactly what was observed, and act on it without asking you to explain. This sub-topic is about the anatomy of that record: what a single finding has to carry — the affected resource and account, the configuration state we actually observed, the specific control clause it speaks to, and a testable fix — before it can stand in front of an auditor, a cyber-insurance reviewer, or your own board. It is deliberately narrower than the parent domain: framework mapping decides which controls a finding touches, while evidence generation is the discipline of writing each finding so that mapping is defensible and independently verifiable. Because the assessment is read-only and point-in-time, every record is framed as evidence of an observed gap or a satisfied control on a given date — not a pass, a fail, or a certification. The result is a report you hand across the table intact, rather than a scanner export you have to translate first.
Overview
What this check looks like in practice
Each finding carries the context an auditor or reviewer needs to act on it: the affected resource, the observed condition, the control it relates to, and the remediation that would close it. We frame this as evidence of a gap or a satisfied control, not as a pass/fail certification, because the assessment is read-only and does not change your environment or your compliance status. The goal is a report you can hand to an auditor, an insurer, or leadership without translating it first.
Why it matters
An auditor cannot accept "S3 bucket public" as evidence; they can accept a named bucket in a named account, the exact public-access state observed, the date it was observed, and the control clause it maps to — because that is something they can re-verify and tie to a requirement. Findings that lack this anatomy get re-litigated every audit cycle, slip between framework owners because nobody can tell whose requirement they satisfy, and can never be proven closed because there is no captured before-state to compare against. From the attacker's side, a vague or unranked finding is one that quietly stays open: the over-privileged role or exposed endpoint that read as low-signal noise is exactly the foothold that gets used. Evidence discipline is also where accuracy is most load-bearing — a record that overstates what was seen, or implies a certification the assessment cannot grant, is worse than no record, because it fails under exactly the scrutiny it was meant to withstand. Getting the finding right once means one body of work serves the audit, the insurance questionnaire, and the remediation ticket without rework.
What we assess
What we look for
- Whether each finding cites the exact resource identifier — an ARN, Azure resource ID, or GCP fully qualified resource name — and the account, subscription, or project it lives in, so it is independently verifiable rather than a paraphrase
- Whether the observed condition captures the real configuration state (the policy JSON, the open port and source range, the encryption flag, the missing MFA) rather than a generic label
- Whether the finding is scoped and dated as a point-in-time observation, so it reads as an evidence record for a specific moment and estate, not an open-ended claim
- Whether it names the specific control clause it evidences — for example PCI-DSS Req. 7.2, SOC 2 CC6.1, or a specific CIS benchmark item — instead of a broad control family
- Whether remediation is stated as a concrete, testable change with a re-verification step, so closure can later be proven with an after-state
- Whether severity reflects real exposure with a stated rationale, not a raw scanner or secure-score number carried over unexamined
- Whether the record distinguishes what the assessment directly observed from control areas that require process or policy artifacts you supply, so coverage gaps are explicit
- Whether the language frames each item as evidence of a gap or a satisfied control and avoids any wording that implies certification or a guarantee
Across your clouds
AWS, Azure & Google Cloud
AWS
Each finding is anchored to the AWS artifacts that already carry point-in-time truth: the resource ARN and account ID, the AWS Config configuration item and its configuration history for the observed state, the CloudTrail event that recorded when a change happened, and IAM Access Analyzer findings for external or unused access. Where useful we align records to the AWS Security Finding Format (ASFF) in Security Hub and to Audit Manager control sets, so the evidence reads in the same schema your team already collects rather than a parallel one.
Azure
Findings cite the full Azure resource ID, subscription, and management group, and draw the observed condition from Microsoft Defender for Cloud recommendations, per-resource Azure Policy compliance state (compliant/non-compliant against a definition), and the Activity Log for the timestamped change record. Azure Resource Graph queries provide the reproducible snapshot, and where relevant we line records up with the Defender for Cloud regulatory compliance dashboard so the evidence speaks your native tooling's language.
Google Cloud
Each finding uses the fully qualified Google Cloud resource name, project, and organization node, with the observed state sourced from Security Command Center findings (which carry resourceName, category, and sourceProperties), a Cloud Asset Inventory point-in-time snapshot, and Cloud Audit Logs for the change record. Organization Policy constraints supply the guardrail context, and Security Command Center's compliance view lets the evidence correlate with the CIS and PCI DSS findings GCP already reports.
Example finding
Findings delivered as flat scanner lines with no resource ID, observation date, or control clause
Risk: A line that reads only "public storage bucket detected" cannot be used as audit evidence: the auditor cannot tell which bucket in which account, cannot re-verify the state, and cannot tie it to a requirement — so it is either rejected or spawns a round of back-and-forth. The same gap means the finding cannot be proven closed later, because no before-state was captured to compare a fix against.
Fix: Reissue each finding as an evidence record: the exact resource identifier and account, the observed configuration state (for a bucket, the S3 Block Public Access settings and ACL/bucket-policy as seen), the date of observation, the specific control clause it evidences (for example CIS AWS Foundations Benchmark 2.1.5 and PCI-DSS Req. 1 and 7), a testable remediation, and an explicit re-check step so closure can be demonstrated in the next cycle.
Remediation
How to close it
- 1 Standardize the finding record so every item carries the same fields: resource identifier and account, observed condition, mapped control clause, severity with rationale, remediation, and the observation date.
- 2 Separate evidence the assessment directly observed from control areas that need process or policy artifacts you own, and flag the latter explicitly rather than leaving them to look covered.
- 3 Route each finding to the accountable framework or resource owner using its control clause, so it lands with someone who can act instead of sitting in a shared queue.
- 4 Remediate the observed condition, then capture the after-state as closure evidence and re-verify against the original record so the fix is provable, not asserted.
- 5 Store each record with its point-in-time context — date, scope, and source artifact — so it is ready to reuse for the audit, the insurance questionnaire, and the board update without reconstruction.
- 6 Re-run the check after material change so evidence stays current, since a point-in-time record ages as the estate drifts.
Compliance evidence
Questions
What actually makes one of your findings usable as audit evidence?
Five things travel with every finding: the exact resource and account it concerns, the configuration state we observed, the date we observed it, the specific control clause it evidences, and a testable remediation. That combination is what lets an auditor or insurer re-verify the observation and tie it to a requirement, instead of taking a summary on faith.
Can we hand a finding straight to our auditor or insurer?
Yes — each finding is written as evidence of an observed condition on a specific date, in the language of the control it touches, so it can go across the table without translation. The auditor still makes the compliance determination; the assessment is read-only and point-in-time, so it supplies evidence rather than a verdict.
How do you handle controls you cannot directly observe?
We separate them out. Where a control depends on process or policy artifacts that live outside the cloud configuration — training records, signed policies, ticket history — we flag it as needing your evidence rather than asserting it is met. That keeps the report honest about what the read-only assessment did and did not see.
More in framework mapping
See where you stand
A health check finds and prioritizes real exposure. It is not a certification or a promise you will never be breached — closing the findings is what changes your risk.
Related domain surfaces
The rest of what we assess
The same read-only assessment covers every domain — see what else it looks at.
