Cloud Scanning: Collect Cloud Compliance Evidence Once for Every Program You Run

If your team is working toward more than one program at once, cloud evidence collection is where the work doubles. You pull configuration evidence out of Amazon Web Services (AWS) for your System and Organization Controls (SOC 2) attestation, then go back for ISO 27001, then again when a customer contract introduces a requirement you had not scoped for. Same environment, same evidence, collected three times.

Cloud Scanning pulls evidence from AWS, Microsoft Azure, and Google Cloud Platform (GCP) once, against whatever framework, standard, or regulation you are working toward. One collection covers every program you are running.

Cloud compliance evidence mapped to your controls

Collection is only half the problem. Evidence that lands in an export still has to be matched to the controls it satisfies, and that matching is what consumes hours in the weeks before an audit window opens. It is also where the errors live, because a person is reading a configuration file and deciding by hand which requirement it answers.

Cloud Scanning maps evidence directly to your controls and puts it in a dedicated view inside Carbide. Scans run automatically every week, so the picture of your environment stays current without anyone opening a cloud console to export it.

Identity and source control evidence coverage

Identity and source control carry as much audit weight as infrastructure configuration. Access reviews and branch protection records get requested in the same evidence lists as encryption settings and logging configuration.

Cloud Scanning connects to GitHub, Google Workspace, and Okta alongside the three cloud providers. That evidence comes through the same path and lands in the same place, so your view holds one picture of your environment rather than a cloud picture plus a pile of screenshots from everywhere else.

What the Cloud Scanning dashboard shows

The Cloud Scanning dashboard opens on the state of your environment against the benchmarks you have enabled. You see how many checks are passing, how many active alarms are open, how many total checks are in scope, and how many findings are overdue against the remediation windows you set.

Findings are grouped by severity so the dashboard answers a specific question: is anything sitting past the window we committed to. Low, medium, and high can all be comfortably inside their limits while critical findings are the ones demanding attention, and the dashboard shows that split rather than a single aggregate score.

A separate errors view covers checks that could not run. These are usually misconfigurations, a missing service, or a missing role in the connected account. They are worth clearing early, because a check that cannot run is not evidence of anything.

Cloud misconfiguration remediation from alarm to fix

Opening a finding gives you the detail behind it. A finding from the AWS SOC 2 benchmark might read “Amazon S3 public access should be blocked at the account level.” You get the description, and a timeline showing when it was first seen, what each weekly scan since has returned, and when it flipped to passing after someone fixed it.

Cloud Scanning also generates remediation guidance for the finding: what is failing and the steps to correct it in your cloud provider’s console. From the same screen you can create a task in Carbide’s task manager, carrying the finding’s details across and assigning it to someone in your organization. The finding then shows that a task exists and what stage it is at, so an open alarm and the work to close it stay attached to each other.

How to scope checks and manage accepted risks

Not every check that fails is a problem you need to fix, and a scanner that cannot be told so becomes noise.

You set the remediation window for each severity, which is what the dashboard measures overdue findings against. You choose which benchmarks appear on your dashboard, and within each benchmark you mark individual checks in scope, out of scope, or not applicable, individually or in bulk.

Findings can be marked as a false positive or accepted as a risk, and you can change a finding’s criticality when your environment gives you reason to. That decision can apply to the whole finding or to a single resource underneath it, which matters when a check flags a list of user profiles and only the account-level ones are the deliberate exception.

Exceptions expire. When the cadence you set comes around, the check is reinstated and the exception has to be made again deliberately. Every change is recorded in a filterable history, so the reasoning behind an accepted risk is still available when someone asks about it a year later.

Adding a framework, standard, or regulation to your program

The value of collecting once shows up the second time you need the evidence.

A team running SOC 2 picks up an enterprise customer whose contract requires ISO 27001. The AWS configuration evidence behind their SOC 2 controls already exists in the platform. Adding ISO 27001 maps that evidence against the new control set rather than sending an engineer back into the console to export it again.

The same holds when a customer questionnaire introduces a requirement you had not scoped for, or when a second cloud provider enters the environment through an acquisition. The collection work does not repeat each time the requirement list grows.

Why control mapping decides your audit outcome

Plenty of tools will pull a configuration export out of a cloud account. The part that decides how your audit goes is whether that evidence is tied to the right control.

That is where the mapping matters. Cloud Scanning ties each check to the control it satisfies, so the work of deciding which requirement a configuration answers is already done by the time your audit window opens. Under a benchmark’s framework requirements you can see the individual control requirements broken out and which of your cloud checks count as evidence and coverage against them.

How to set up Cloud Scanning

Step 1: Connect your cloud accounts. Cloud monitoring integrations sit in their own section of the platform, separate from the general integration list. Choose a provider, review the capabilities it covers, and supply the credentials for that account.

Step 2: Enable the benchmarks you need. A default set is available on connection, covering what most compliance programs are built on: Center for Internet Security (CIS) baselines, National Institute of Standards and Technology (NIST) publications, Federal Risk and Authorization Management Program (FedRAMP) baselines, the Payment Card Industry Data Security Standard (PCI DSS), and the Health Insurance Portability and Accountability Act (HIPAA). If a benchmark you need is not in the default set, ask Carbide to enable it or to have one created for your program.

Step 3: Configure the scan. Set your remediation window for each severity, choose which benchmarks appear on your dashboard, and mark individual checks in or out of scope.

Step 4: Work the dashboard. Review priority findings, generate remediation guidance, and create tasks for the work that needs owners.

See what Cloud Scanning covers in your compliance program

How much of your evidence requirement Cloud Scanning satisfies depends on what you have connected and your compliance goals. Carbide maps the scan results against your current control set to tell you which requirements are already covered.  Talk with our team to see Cloud Scanning in action.