Cloud security requires continuous visibility across providers, accounts, regions, resources, identities, networks, data stores, and configurations. Cloud posture can change quickly, so governance must combine scanning, risk prioritization, remediation, evidence, and reporting. CloudSignals+RiskOps provides multi-cloud posture visibility, scan intelligence, findings analysis, compliance status, asset context, risk prioritization, and remediation workflows.
Topic course: ~90 min • Certification path: 5–7 hrs 6 modules + capstone Foundational to Intermediate Certification eligible
Who this course is for
Cloud security engineers
Cloud operations teams
Security and compliance analysts
MSP cloud operators
DevSecOps engineers
Prerequisites
Basic familiarity with cloud providers and cloud services
Basic understanding of security findings and cloud misconfigurations
Access to CloudSignals scans, findings, and asset views
What you will be able to do
Explain core cloud security domains and posture management concepts.
Navigate provider, scan, asset, finding, and compliance views in CloudSignals+RiskOps.
Interpret cloud findings and their business impact using asset context.
Explain the difference between scanner compliance views and UCB governance assurance.
Route cloud security gaps into RiskOps remediation with evidence requirements.
Use Vision to investigate findings and draft remediation guidance — with required human validation.
Platform areas used in this course: Overview, Surface, Assets, Cloud Resources, Scans, Findings, Compliance, Governance & Assurance, Framework Explorer, RiskOps, Vision, Reports. Navigate to Overview in the main navigation to begin.
AI advisory statement: Vision and other AI-assisted workflows are advisory. Scanner compliance views reflect metadata — they are not certification statements. UCB governance requires evidence and human validation. Vision output must be reviewed and attested before use as governance or audit evidence.
1
Cloud Security Operating Model
15 min • Overview • Explain posture management and risk signal concepts
Continuous visibility across providers, accounts, and resource types
Cloud security posture management (CSPM) provides continuous evaluation of cloud resource configurations against security policy controls. Unlike point-in-time assessments, CloudSignals+RiskOps runs on a defined cadence — evaluating every connected resource against every active policy check and updating the findings inventory in near-real-time. When a resource configuration drifts from the expected state, a finding is created. When a finding is remediated and a subsequent scan confirms the fix, the finding closes.
The operating model combines five capabilities: Scanning (automated evaluation of cloud resource configurations), Risk prioritization (asset context, business impact, exposure, and age applied to findings), Remediation (RiskOps treatment plans with owner, due date, and evidence), Evidence (scan results and configuration exports linked to UCB controls), and Reporting (posture summaries and executive narratives from the Reports and Vision modules).
In the platform — Review the Overview dashboard
1
Navigate to Overview. Review: threat score, findings by severity, findings discovered vs. closed, top risk drivers, and connected provider summary.
2
Note the provider coverage strip — which cloud providers are connected and contributing findings? Any gap here is a blind spot in your posture visibility.
3
Review the top risk drivers panel. These are the finding categories currently generating the most risk pressure across your environment — the areas to prioritize for this session's work.
Confirm all expected providers are connected: Compare the Overview provider list against your actual cloud footprint. Any missing provider is a governance blind spot.
Note your current threat score: Record the score as your baseline. Return to this after completing the course's in-platform labs to observe improvement.
Identify your top three risk drivers: Note the finding categories driving the most risk pressure — these become your priority focus for Modules 4 and 6.
Knowledge Check
What does scan scope include in CloudSignals+RiskOps?
Only the resource types flagged as critical by the connected provider's native security service.
Provider, account or subscription, region, service coverage, credential model, scan timestamp, completed versus pending state, and error or missing snapshot state — all of these determine what was actually evaluated in a scan cycle.
All resources in all regions for all providers connected — scope is always complete once a provider is added.
Only the resources that generated findings in the previous scan — unchanged resources are excluded to reduce scan time.
Move on when you've reviewed the Overview dashboard and noted your top risk drivers.
2
Scan Lifecycle
20 min • Scans • Understand scan execution, scope, and freshness
Eight dimensions of scan scope
A completed scan status does not mean all resources were evaluated. Scan scope is constrained by what the connector has permission to see. Resources in accounts, regions, or service types lacking read access are silently excluded — they don't generate findings, but they aren't compliant either. They're invisible. Understanding all eight dimensions of scan scope is essential for understanding what your posture data actually covers:
Provider
AWS, Azure, GCP, OCI, Kubernetes, M365
Account / subscription
Which accounts are in scope?
Region
Which regions are evaluated?
Service coverage
Which resource types are checked?
Credential model
What permissions does the connector have?
Scan timestamp
When did this scan run?
Completed vs. pending
Did all checks finish successfully?
Error / missing snapshot
Were any services excluded due to errors?
Why scan freshness matters for governance
A scan that ran 14 days ago is not evidence that your current posture is as described. Resources change — instances are provisioned, permissions are modified, configurations drift. Scan freshness is how recent the scan data is relative to the governance period being reported on. For compliance evidence, the scan must have run during the audit period. For active risk management, stale scans mean findings that should have been detected are invisible, and findings that were remediated may still show as open.
In the platform — Lab 1: Cloud Scan Review
1
Navigate to Scans. Review the scan list: provider, account, status, last run timestamp, and resource count discovered.
2
Select a completed scan. Review the scope: which accounts, regions, and service types are covered. Compare against your known cloud footprint — note any gaps.
3
Check scan freshness: how old is the most recent completed scan for each provider? Any scan older than your cadence requirement (typically 24–72 hours) represents a posture visibility gap.
4
Identify any scans with error or missing snapshot state. Review the error details — these indicate configuration or permission issues that are silently excluding resources from evaluation.
5
Record your scan review summary: which scans are fresh, which are stale, and which have scope gaps. This is your Lab 1 deliverable.
Verify all connectors completed successfully: Any connector with a failed or stale last-scan state represents a posture visibility gap that may be masking open findings.
Cross-reference scope vs. footprint: For each provider, compare connector scope against your known active accounts, subscriptions, and regions. Document any gap.
Confirm scan cadence alignment: Verify your scan schedule meets your governance and compliance requirements for scan freshness during evidence collection periods.
Knowledge Check
Why should scan freshness be reviewed as part of cloud security governance?
Older scans have higher CVSS scores assigned to their findings — freshness affects the severity calculation.
Stale scans mean the posture data doesn't reflect the current cloud state — resources that changed since the last scan are invisible. For compliance evidence, scans must be within the audit period. For active risk management, stale data means undetected exposure and remediated findings that still appear open.
Scan freshness only matters for penetration testing engagements — CSPM scans can be run quarterly without governance impact.
Fresher scans generate more findings — reviewing freshness helps teams prepare for an increase in workload after a scan cycle completes.
Move on when you've reviewed scan scope, freshness, and confirmed all connectors completed successfully.
3
Cloud Asset Posture
20 min • Assets, Cloud Resources • Review cloud resource posture by provider and account
Cloud assets as the governance anchor for findings
Cloud assets include resources, identities, storage, workloads, networking components, services, and integrations. In CloudSignals+RiskOps, asset context helps learners understand which findings matter most and where ownership gaps exist. A finding on an unowned asset is an orphaned signal — no one routes it, no one remediates it, and the exposure window stays open indefinitely.
The Cloud Resources view groups assets by provider and account, allowing governance teams to identify: which providers contribute the most findings, which accounts have the highest finding density, which resources are internet-facing (highest priority), and which assets lack ownership or managed entity assignment (mapping gaps that inflate risk pressure).
In the platform — Lab 2 setup: Inspect cloud asset posture
1
Navigate to Surface > Cloud Resources. Group by provider. Review asset counts per provider and compare against your expected footprint.
2
Filter for internet-facing resources (public exposure flag). These are your highest-priority governance targets — public resources with open findings have the shortest path from detection to exploitation.
3
Navigate to Surface > All Assets. Filter for assets with no owner or no managed entity assigned. These ownership gaps create mapping issues that inflate risk pressure scores — prioritize assigning ownership to any Critical or High criticality assets without an owner.
4
For the provider with the highest finding count, click into the account breakdown. Identify whether findings are concentrated in one account or distributed. Concentrated findings often indicate an account-level misconfiguration (e.g., missing security baseline policy) rather than individual resource issues.
Confirm all cloud accounts appear in Cloud Resources: Any account present in your billing console but absent from Cloud Resources is a scope gap — all findings in that account are invisible.
Identify your highest-finding account: Determine whether findings are concentrated (account-level issue) or distributed (individual resource issues). This determines whether your fix is a policy baseline or individual resource remediation.
Assign ownership to unowned high-criticality assets: Every public-facing and critical-classified cloud asset must have an owner and managed entity before findings can be properly routed for triage.
Knowledge Check
Name four common cloud misconfiguration categories that CloudSignals+RiskOps detects through policy checks.
Slow DNS resolution, high memory utilization, unoptimized storage costs, and expired TLS certificates on internal services.
Public exposure (storage/endpoints open to the internet), weak encryption (missing or insufficient at rest/in transit), excessive permissions (overly broad IAM roles or policies), and missing logging (CloudTrail, diagnostic settings, or audit logs disabled).
Misconfigured backup retention, over-provisioned compute, untagged resources, and orphaned snapshots.
Network latency above SLA threshold, unbalanced load balancer targets, missing health checks, and auto-scaling misconfigurations.
Move on when you've reviewed Cloud Resources, confirmed scope coverage, and assigned ownership to unowned high-criticality assets.
4
Findings & Misconfigurations
25 min • Findings • Interpret cloud checks and extract business context
Evaluating a cloud finding — eight questions
Common cloud findings include public exposure, weak encryption, excessive permissions, missing logging, insecure network rules, unsupported or end-of-life configurations, and lack of monitoring. When investigating any cloud finding, apply these eight questions to extract the full risk context before deciding on a treatment:
What service or resource is affected? — storage bucket, IAM role, database, VM, network security group?
Is it internet-facing? — public exposure shortens the exploitation window significantly.
What data or business function is involved? — PII, financial, regulatory, critical operations?
Is there an owner? — unowned resources can't receive a treatment assignment.
Is the finding recurring? — re-emerging findings after remediation indicate a systemic root cause.
What remediation evidence is required? — define this before creating the treatment plan.
What is the finding age? — findings aging past SLA need immediate escalation.
Is this intentionally configured? — some findings represent known-acceptable states that need suppression or formal acceptance, not remediation.
In the platform — Lab 2: Cloud Finding Investigation
1
Navigate to Findings. Filter to Critical severity, status = Open. Apply the eight-question framework to the top three findings.
2
For each finding, click through to the linked asset. Review: resource type, internet-facing status, data type, owner, and business process linkage. Note how asset context changes your prioritization.
3
Review the remediation guidance in the finding detail. For one finding, document: what specifically needs to change (configuration, permission, policy), the exact cloud provider steps to make the change, and what evidence will confirm the fix (post-fix scan + configuration export).
4
For any finding on an intentionally-configured resource (e.g., a public bucket serving a static website), create a formal acceptance with justification — removing it from the active finding queue with a documented rationale rather than leaving it as an unaddressed signal.
Apply the eight-question framework to all Critical findings: No Critical finding should be triaged on severity alone — asset context changes priority in most cases.
Define remediation evidence upfront: For each treatment plan created this session, document the required evidence before assigning the work — not after the engineer asks "how do we close this?"
Formally accept intentional exceptions: Any finding representing a known-acceptable state should be formally accepted with justification — not left as an unaddressed open signal polluting your risk score.
Knowledge Check
What is the difference between scanner compliance views and UCB governance assurance in CloudSignals+RiskOps?
Scanner compliance views are real-time; UCB governance assurance is updated only during quarterly reviews. The difference is timing, not content.
CloudSignals Compliance views show scanner-derived framework posture for completed scans — metadata about configuration state. Governance & Assurance UCB views represent source-attributed governance mappings and tenant assurance state with human-reviewed evidence. Scanner compliance metadata is not the UCB source of truth and must not be treated as certification evidence.
UCB governance assurance replaces scanner compliance views for customers who have completed the full UCB onboarding — they are not available simultaneously.
Scanner compliance views apply to cloud providers; UCB governance assurance applies to on-premises systems. They cover different environments.
Move on when you've investigated your top Critical findings with full context and formally accepted any intentional exceptions.
5
Compliance & UCB Boundary
20 min • Compliance, Framework Explorer • Explain the scanner metadata vs. governance source boundary
The boundary that protects governance integrity
This is the most important conceptual boundary in CloudSignals+RiskOps for governance practitioners: CloudSignals Compliance views show scanner-derived framework posture for completed scans. Governance & Assurance UCB views represent source-attributed governance mappings and tenant assurance state. Learners must not treat scanner compliance metadata as the UCB source of truth.
Why does this boundary matter? If a scanner passing a CIS Benchmark check automatically counted as SOC 2 compliance evidence, organizations could achieve compliance certifications without any human-reviewed evidence, without Assessment Objective completion, and without the accountability that makes governance defensible. Scanner metadata is a valuable input — it can contribute to evidence — but it does not certify compliance. The UCB, with its source-attributed mappings, human-reviewed evidence, and AO results, is the governance authority.
A high Compliance view score ≠ compliance certification. Use Compliance views for posture trending and gap identification. Use Governance & Assurance for assurance decisions and audit evidence. These are two different tools for two different purposes.
In the platform — Review Compliance views and Framework Explorer
1
Navigate to Compliance. Review your framework posture scores for the most recent completed scans. Note these scores as posture indicators — not compliance certifications.
2
Identify the three compliance framework categories with the lowest posture scores. These are your technical remediation priorities — the control areas where scanner-detectable gaps are most prevalent.
3
Navigate to Governance & Assurance > Framework Explorer. Select the same framework. Review which UCB controls map to the low-scoring categories. Note: the UCB controls require evidence and AO completion — a passing scanner check satisfies neither by itself.
4
For one low-scoring control, navigate to Evidence Fabric and check whether evidence exists. A control can have a passing scanner result and still be "Not Assessed" in the UCB — because scanner data alone doesn't satisfy the AO. Confirm what additional evidence is needed.
Review Compliance view posture for your primary framework: Note the score and lowest-scoring categories — use these as technical remediation targets, not compliance certification inputs.
Cross-reference with Evidence Fabric: For your lowest-scoring control categories, confirm whether UCB evidence exists beyond the scanner result. Identify what additional evidence is needed to satisfy the AOs.
Communicate the boundary to your team: Write a one-paragraph policy statement for your team explaining when to use Compliance views vs. when to use Governance & Assurance for evidence decisions.
Knowledge Check
When should a cloud finding become a RiskOps project rather than a standalone treatment plan?
All cloud findings should be individual treatment plans — RiskOps projects are only for multi-year remediation programs.
Cloud findings should become RiskOps projects when they require multi-team coordination, milestone tracking, external dependencies (vendor patching, migration timeline), executive visibility, SLA policy enforcement, or formal evidence requirements that span multiple work items and owners.
Only Critical severity findings become RiskOps projects — Medium and Low findings remain as standalone treatment plans regardless of complexity.
Findings automatically become RiskOps projects when they exceed 30 days without a treatment record — the platform handles this conversion without manual action.
Move on when you understand the scanner/UCB boundary and have cross-referenced Compliance view gaps with Evidence Fabric.
6
Remediation & Reporting
25 min • RiskOps, Vision, Reports • Create action plans and executive posture summaries
Routing cloud findings into RiskOps
Cloud remediation should be routed into RiskOps when it requires ownership, due dates, evidence, acceptance, or executive visibility. Not every finding needs a formal project — but every finding that touches a crown-jewel asset, a regulatory obligation, or a business-critical service needs a named owner and a verifiable closure path. Vision can help explain cloud findings and draft recommended actions, but all Vision output requires review before use as governance evidence or distribution.
In the platform — Lab 3: Cloud Posture Executive Summary
1
Navigate to Overview. Review the top risk drivers, threat score trend, and findings discovered vs. closed. These are the three core metrics for an executive cloud posture summary.
2
Navigate to Reports. Select AI Intelligence Brief or RiskOps Insights. Generate a posture report for the current period. Review findings by provider, remediation themes, and compliance readiness.
3
Navigate to Vision > Ask Vision. Request a cloud posture executive summary: "Summarize our cloud security posture including top misconfiguration themes, highest-risk findings, and three prioritized remediation recommendations."
4
Review the Vision output against your Reports data. Correct any inaccuracies — Vision may reference findings or metrics from earlier in the reporting period. Add your reviewer attestation and AI advisory disclaimer.
5
Assemble your Lab 3 deliverable: the validated Vision executive summary plus the remediation recommendations from your finding investigations in Module 4. This is a complete cloud posture review package.
Create RiskOps treatment plans for your Module 4 findings: Every Critical finding investigated in Module 4 should now have a treatment plan with owner, target date, and evidence requirement.
Generate and validate a Vision executive summary: Verify against Reports data, correct inaccuracies, add your attestation and AI disclaimer before distributing.
Schedule recurring cloud posture reporting: Set a monthly calendar entry to generate the posture report and distribute to security leadership. Quarterly is insufficient for active cloud environments.
Knowledge Check
A Vision-generated cloud posture summary identifies three critical misconfigurations. What must happen before this summary is distributed to the executive team?
The CISO must approve the summary format — Vision output is automatically accurate but requires executive sign-off for distribution.
A named reviewer must verify each cited misconfiguration against current platform data, correct any inaccuracies or outdated metrics, add context specific to the organization, and attach a reviewer attestation plus an AI advisory disclaimer before distribution.
Vision output can be distributed directly to executives — it is drawn from live platform data and does not require additional review before senior distribution.
The three misconfigurations must be fully remediated before the summary can be distributed — executives should only receive posture summaries reflecting a fully remediated state.
Move on when treatment plans are created for your critical findings and you've produced a validated executive posture summary.
Certification: AiVRIC Cloud Security Practitioner
Completing all six modules makes you eligible for the Cloud Security Practitioner certification exam.
Exam domain
Weight
Cloud security concepts
20%
Scan lifecycle and scope
20%
Findings and asset posture
25%
Compliance and UCB boundary
20%
Remediation and reporting
15%
Capstone practical scenario
A tenant has completed an AWS scan showing public exposure findings, weak logging configurations, and excessive IAM permissions on several accounts. Compliance readiness is incomplete and several findings affect critical assets. Your task:
Review scan scope to confirm all accounts and regions were evaluated.
Apply the eight-question framework to the top three findings and rank by true risk priority.
Explain why the Compliance view score is not a compliance certification — describe what additional evidence is required.
Recommend remediation for the highest-priority finding with owner, target date, and evidence requirement.
Draft an executive cloud posture summary using Vision, validate it, and attest it with AI disclaimer.
Passing criteria: Correctly interprets scan scope and identifies any gaps. Prioritizes cloud risks using asset context rather than severity alone. Preserves the UCB governance boundary — does not equate scanner compliance with assurance. Produces actionable remediation with evidence requirements. Vision output is validated, corrected, and attested with AI disclaimer.
🏅
Course complete!
You've completed Cloud Security. Your CSPM program now connects scan results to governance decisions — with the UCB as the authoritative boundary.
