Use Case

CSPM finding remediation workflow
one operational record for every cloud misconfiguration

Cloud security posture management tools surface thousands of misconfiguration findings across AWS, Azure, GCP, and Kubernetes accounts. Run those findings through a single engagement record so intake, deduplication, severity calibration, owner routing, exception expiry, retest verification, and audit evidence land in one place rather than fanning out across the CSPM console, the ticketing queue, the chat thread, and the spreadsheet.

Get Started Free

No credit card required. Free plan available forever.

Take cloud security posture findings off the vendor console and onto the engagement record

Cloud security posture management tools (CSPM modules inside Wiz, Prisma Cloud, Defender for Cloud, AWS Security Hub, GCP Security Command Center, Orca, Tenable Cloud Security, and native hyperscaler services) surface thousands of misconfiguration detections per cloud account. They do the detection well. They do not do the operational lifecycle that turns detections into closures the audit can read. Internal cloud security teams, AppSec teams, security engineering teams, and GRC teams pay the cost together when CSPM findings live only inside the vendor console: deduplication against IaC scanning and external scans never happens, severity defaults stick because nobody recalibrates against runtime exposure, exceptions accumulate as console suppressions with no expiry, closures rely on auto-close instead of operator verification, and the leadership posture read is rebuilt every quarter from a CSV export the analyst pivots in Excel.

This is the operational layer between CSPM detection and the audit. For the broader cloud assessment programme that the workflow runs inside, read the cloud security assessment workflow. For the upstream scanner integration that produces the findings, read the scanner result triage workflow and the SDLC vulnerability handoff workflow. For the structured exception flow this lifecycle depends on, read the vulnerability acceptance and exception management workflow. For the related background reading on the CSPM category, the CSPM explainer and the cloud security assessment guide cover what the detection layer is and how an assessment programme operates against it.

Six cloud finding sources and how the workflow reconciles them on one record

Cloud security findings arrive from six places. Each source has a healthy posture (the detection lands on the engagement record with the cited control reference and named owner) and a default failure (the detection lives in the source tool, ages there, and never reconciles against the rest of the cloud posture). The split below is the starting point for an operational model internal cloud security teams and platform engineering teams can both run against.

Source	Healthy posture	Default failure
Wiz, Orca, Prisma Cloud, and other CNAPP CSPM modules	Findings export as CSV with the cloud resource id, the cloud account id, the control reference, the source, the detection timestamp, and the suggested fix. Bulk finding import maps the columns onto the engagement record and the cross-engagement view surfaces duplicate candidates against prior cycles before the team starts triaging from scratch.	The CSPM console becomes the only place the findings live. The team triages from the vendor UI, ages findings inside the vendor system, and rebuilds the consolidated picture every leadership cycle from a screenshot. There is no record outside the console, no deduplication against last quarter, and no audit trail when the vendor licence lapses.
Hyperscaler-native posture services (AWS Security Hub, Defender for Cloud, GCP SCC)	Each cloud account or subscription has an engagement record. Native findings export as CSV from the hyperscaler service and ingest through bulk finding import. Control references from the hyperscaler standard (CIS Foundations, AWS Foundational Security Best Practices, NIST 800-53 mapped pack, CSA CCM) land alongside the detection so the audit lookback reads the source as a documented standard rather than as an opaque rule id.	The cloud team treats Security Hub or Defender as the source of truth and the security team treats the CSPM as the source of truth. Two posture surfaces show different numbers because they have different rule packs, different update cadences, and different in-scope account lists. The leadership review picks the higher or lower number depending on the audience and the audit asks for the reconciliation.
Infrastructure-as-code static scanning (Checkov, tfsec, Snyk IaC, Bridgecrew)	IaC findings raised at the pull-request stage route to the engagement record with the named developer owner, the affected module, the cited control reference, and the calibrated severity. The same engagement record holds the runtime CSPM finding for the deployed resource so the design-time and runtime views reconcile to one identity rather than living in separate consoles.	IaC scanning runs in CI and posts results to a PR comment that nobody re-reads after merge. The runtime CSPM picks up the same finding three days later and the team triages it again as a new issue. The PR comment is gone, the runtime ticket is new, and the team relives the same triage every cycle. The same finding lives a separate life at each stage gate.
External attack surface scanning against cloud-hosted endpoints	External scans cover internet-facing cloud endpoints (ingress controllers, load balancers, public buckets, exposed admin paths) and recalibrate severity against runtime exposure. The engagement record holds the CSPM rule reference alongside the external scan evidence so the audit lookback reads the runtime confirmation rather than the static control violation alone.	External scanning runs against a different inventory than the CSPM. The two tools surface different findings on the same resource because they read different attack surfaces and the team has no shared engagement record to reconcile them on. Resources move between accounts and the inventory drift surfaces only at the next audit.
Manual cloud security review, threat modelling, and tabletop output	Cloud architecture review findings, threat-model conclusions, and tabletop-derived gaps land on the engagement record as structured findings with severity, named owner, and remediation guidance. The platform record holds the human review output alongside the scanner detections so the leadership view reads the full picture rather than just the automated half.	Architecture review findings live in a Confluence page nobody updates, threat-model conclusions live in a Miro board the next refresh erases, and tabletop output lives in a shared drive folder the new joiner cannot find. None of the human review ever enters the operational queue, and the next audit treats the manual review as undocumented.
Third-party cloud pentest reports and configuration audits	External cloud pentest reports and audit-firm configuration reviews land on the engagement record through the third-party penetration test report intake workflow. Findings extract from the PDF or DOCX into structured records with severity, control reference, and remediation guidance so the external report becomes operational work rather than a static artefact.	A six-figure cloud pentest report sits in a shared drive and nobody operationalises the findings. The remediation plan lives in the appendix of the report. The next pentest cycle re-finds the same issues because the prior cycle never closed inside the operational queue.

Six failure modes that quietly break a CSPM remediation programme

CSPM programmes rarely fail at the moment they go wrong. They fail at the next audit lookback, the next public-bucket disclosure, the next acquisition-driven account merge, or the next leadership briefing where the posture number does not reconcile to the vendor console. The failure modes below are the patterns the workflow is designed to remove.

CSPM console is the only operational surface

The team triages from the vendor UI, ages findings inside the vendor system, and rebuilds the consolidated picture every leadership cycle from a CSV export the analyst pivots in Excel. There is no engagement record, no deduplication against prior cycles, no exception expiry trail, and no closure narrative when the vendor licence lapses or the account migrates to a different provider.

Duplicate findings accumulate across consoles, cycles, and IaC

The same misconfiguration shows up as a CSPM detection at runtime, an IaC scanner finding at pull-request time, and an external scan signal on the public endpoint. Three sources surface what is operationally one issue, and the team triages each one separately because there is no shared identity record. The same closure narrative is written three times and the audit cannot tell how many cloud findings actually existed.

Severity defaults stick because nobody recalibrates against runtime context

A public S3 bucket and an internal staging bucket land at the same severity because the CSPM rule pack does not know which one holds production customer data. The team treats every finding the same and the leadership scorecard reads the same number it read last quarter. Calibration that should be a state event becomes drift, and the audit lookback reads the wrong severity profile because nobody recorded the calibration decision.

Exceptions are negotiated in chat and never expire

A team accepts a finding "for the quarter" because the remediation is blocked on a vendor change. The decision lives in a Slack thread, the CSPM console marks the finding as suppressed forever, and twelve months later nobody remembers why the suppression exists. The next audit reads an active exception with no approver, no rationale, and no expiry. The structured override workflow exists for exactly this case; without it suppressions accumulate as silent drift.

Closures rely on CSPM auto-close instead of operator verification

The CSPM rule stops firing after a fix lands and the console auto-closes the finding. The team trusts the auto-close and moves on. The audit then asks for the evidence that the fix actually addressed the underlying issue and the team has nothing beyond the absence of the rule firing. Verification is not an auto-close; it is a recorded retest with cited evidence on the engagement record.

Cloud findings never feed the leadership posture read

Vulnerability management reports include scanner findings, pentest findings, and SAST findings but treat CSPM as a separate world the cloud team manages alone. The CISO reads two parallel posture stories that never reconcile. When the next ransomware briefing asks for the cloud misconfiguration risk profile, the team has to assemble it manually from a vendor export. Cloud findings belong on the same engagement spine the rest of the programme runs against.

Six fields every CSPM finding record has to carry

A defensible CSPM finding record is six concrete fields on the engagement, not an abstract paragraph in a cloud security policy document. Anything missing from the list below is a known gap in the operational discipline rather than a detail that surfaces later as an audit finding or as a public disclosure.

Cloud account or subscription identifier and provider

The cloud provider (AWS, Azure, GCP, OCI, Alibaba, multi-cloud) and the account, subscription, project, or organisation-unit identifier the finding belongs to. The CSPM finding inherits the cloud surface from the engagement record so the audit lookback reads which account the misconfiguration applied to rather than guessing from the resource name.

Resource identifier, region, and resource type

The cloud resource id, the region, the resource type (S3 bucket, IAM role, KMS key, security group, RDS instance, Kubernetes namespace, function), and the resource criticality. Resource granularity drives the routing decision and the severity calibration. A public S3 bucket holding marketing assets is not the same finding as a public S3 bucket holding production backups.

Source CSPM, IaC, or scanner tool and source rule id

The detection source (Wiz, Prisma Cloud, Defender for Cloud, Security Hub, Orca, Tenable Cloud, Checkov, tfsec, Snyk IaC, external scan) and the source rule reference. The audit lookback uses the source rule id to reconstruct why the finding fired and which control standard it maps against rather than reading a generic finding title.

Control reference and framework mapping

The mapped control reference (CIS Foundations 1.20, AWS FSBP, NIST 800-53 AC-3, CSA CCM IAM-09, ISO 27017 cloud control) so the finding rolls up into compliance evidence rather than living in a vendor-specific taxonomy. Cross-framework crosswalks happen on the engagement record so one finding satisfies multiple audit reads rather than getting re-collected per framework.

Named cloud owner and remediation SLA tier

The named owning team or engineer (cloud platform team, application owner, data team, identity team) and the SLA tier the finding inherits from the engagement criticality. Findings without a named owner are themselves a defect rather than a routing convenience.

Override or exception state with expiry and approver

When a finding is a documented false positive, an accepted risk, or a severity override, the structured record carries the cited reason, the named approver, the documented expiry date, and the compensating controls. The override survives the next CSPM ingestion cycle so the next scan inherits the decision rather than re-creating the duplicate on the open queue.

CSPM remediation lifecycle checklist

At weekly cloud triage and at the quarterly leadership review, the cloud security lead, the AppSec lead, the cloud platform owner, and the GRC lead walk through a short checklist. Each item takes minutes; missing any one of them is the source of the failure modes above and the audit gaps that follow.

Every cloud account, subscription, project, or business-unit boundary has a registered engagement with named owner, tier classification, in-scope service surface, and framework mapping before any CSPM ingestion lands.
CSPM exports ingest through bulk finding import with column mapping autodetection so the engagement record collects the posture rather than the vendor console.
IaC scanner findings, runtime CSPM findings, external scan signals on cloud endpoints, and manual review output land on the same engagement record so design-time and runtime views reconcile to one identity.
Cross-engagement finding search runs before triage so duplicate candidates from prior cycles surface as candidates for merge-and-supersede rather than re-entering the open queue.
Severity recalibration against runtime context lands as a state event with timestamp and user attribution rather than as an inline edit nobody can later reconstruct.
Critical and high findings route to the named cloud owner with the cited remediation guidance, the targeted resolution date, and an inbox notification.
Exceptions and recurring scanner-artefact suppressions ride on the structured finding overrides workflow with cited reason, named approver, expiry date, and target resource scope.
Fix verification runs as a recorded retest with cited evidence; CSPM auto-close is not a substitute for operator verification on the engagement record.
Reopen state restores the original finding identity when a regression detection lands on a future scan rather than minting a fresh record.
Document management holds the supporting evidence (cloud console screenshots, IaC diffs, policy text, control-mapping memos, third-party pentest excerpts) so the audit reads the artefacts alongside the closure narrative.
AI report generation derives the leadership posture read from the live engagement record so the headline figure always reconciles to the underlying finding count.
The activity log export covers ISO 27001 Annex A 8.21 to 8.23, NIST 800-53 SI-2 and SI-5, CSA CCM IAM and IVS domains, and SOC 2 CC7.1 to CC7.4 by deriving the trail from the same record the cloud team operates against.
Continuous monitoring schedules keep the cloud posture verdict fresh between CSPM scans so drift between cycles lands as state events rather than as surprises at the next audit.
Quarterly leadership reads cloud posture from the live engagement record rather than from a hand-assembled CSV export the analyst spent the prior week reconciling across consoles.

How the CSPM remediation workflow looks in SecPortal

The workflow runs on the same feature surfaces the rest of the security programme already uses: the engagement record, the findings record, bulk finding import, finding overrides, external and authenticated scanning, continuous monitoring, document management, the activity log, and AI report generation. The discipline is binding the cloud posture lifecycle to a single record so deduplication, calibration, routing, exception, and verification are derivable from the same surface platform engineering, cloud security, AppSec, and GRC already operate against.

Cloud account engagement records

One engagement record per cloud account, subscription, project, or business-unit boundary, carrying the cloud provider, the account identifier, the named owner, the SLA tier, the in-scope service surface, and the framework mapping. The engagement is the operational contract every CSPM finding lands on.

CSPM export ingestion through bulk finding import

Bulk finding import ingests CSPM CSV exports onto the engagement with column mapping autodetection. The cloud resource id, the region, the control reference, and the detection timestamp map onto the finding so the lifecycle starts on a structured record rather than from a raw vendor export.

External and authenticated cloud scanning

External scanning covers internet-facing cloud endpoints and authenticated scanning hits cloud-hosted applications behind login. Findings recalibrate severity against runtime exposure so a public S3 bucket holding production data and a public S3 bucket holding marketing assets read at different priority rather than at the same CSPM default.

Structured override and exception register

Finding overrides hold false-positive suppressions, accepted-risk decisions, and severity overrides with cited reason, named approver, target resource scope, and expiry date. The decision survives the next CSPM ingestion cycle so suppressions stop accumulating silently in the vendor console.

Retest verification workflow

Retesting workflows verify cloud fixes through cited evidence rather than CSPM auto-close. The original record carries the resolved and verified state with separate timestamps, and reopen handling restores the same identity on a regression detection rather than minting a fresh finding for the same underlying issue.

Activity log as the audit trail

Every CSPM ingestion, severity recalibration, override decision, retest verification, and exception expiry lands on the activity log with timestamp and user attribution. The CSV export is the evidence trail behind ISO 27017, CSA CCM, NIST 800-53 CM and SI families, SOC 2 CC7, and PCI DSS Requirements 6 and 11.

Five views the cloud posture programme actually drives

The reports that drive cloud posture governance are not the static slide that lands at a quarterly review. They are the live views the cloud security team, AppSec, and security leadership read between reviews. The five below are the ones every meaningful CSPM remediation programme settles on, and they all derive from the live engagement record rather than a parallel CSPM-tool extract or a hand-built coverage spreadsheet.

Open finding count by severity and account

The headline view leadership reads first. Open and pending CSPM findings by severity, by account or subscription, and by control reference. The view that shows whether cloud posture is trending up or down across the estate rather than from a single vendor console.

Remediation velocity and SLA breach posture

Time-to-resolve by severity, in-flight findings approaching SLA breach, and SLA breach trend by account. The view that distinguishes a working cloud remediation programme from a queue that quietly ages while the headline numbers stay stable.

Exception register and approaching expiries

Active risk acceptances and false-positive overrides with cited reason, named approver, target resource scope, and expiry. The view that distinguishes time-bound exceptions from drift and surfaces approaching expirations before they go silent.

Severity recalibration trail

Severity recalibrations against runtime context with named approver and cited rationale. The view that catches downward severity drift before the audit lookback reads a different severity profile than the CSPM detection produced.

Framework coverage and audit-trail export

Mapped control coverage across ISO 27017, CSA CCM, NIST 800-53, SOC 2, PCI DSS, NIS2, and DORA. The view the GRC team uses to assemble assessor evidence without re-doing the mapping per audit cycle, plus the activity-log export that is the trail behind the coverage figures.

What auditors expect from a CSPM finding remediation programme

CSPM evidence surfaces in audit reads whenever an external assessor reviews cloud security operations. The frameworks below all expect the programme to show that cloud misconfigurations are detected, named, owned, calibrated, remediated, and exception-handled on a defined timeline. A documented cloud security policy without operational evidence on the record reads as a process gap.

Framework	What the audit expects
ISO 27017 (cloud security)	ISO 27017 augments the ISO 27001 control set with cloud-specific controls including 5.1.1 shared responsibility, 6.1.5 information security in project management, 9.1.1 access control to cloud services, 9.2.5 privileged access to cloud services, 13.1.3 segregation of cloud networks, and 18.1.5 cryptographic key management. The CSPM finding remediation workflow produces the evidence assessors expect against these controls by holding each cloud finding on a record with the cited cloud account, the named owner, the calibrated severity, the structured exception trail, and the activity-log entry.
CSA Cloud Controls Matrix (CCM)	CCM domains including IAM (identity and access management), IVS (infrastructure and virtualisation security), DSI (data security and information lifecycle), and EKM (encryption and key management) expect documented monitoring of cloud configurations, named ownership, remediation evidence, and exception handling. Mapping CSPM detections to the CCM control reference on the engagement record produces the assessor-ready evidence behind the maturity claim.
NIST SP 800-53	Control families CM (configuration management), SI (system and information integrity), AC (access control), AU (audit and accountability), and RA (risk assessment) expect documented vulnerability tracking, remediation timelines, and exception handling for cloud-resident systems. The engagement record produces CM-2 baseline configuration evidence, SI-2 flaw remediation evidence, RA-5 vulnerability scanning evidence, and AU-2 to AU-12 audit-trail evidence in one place rather than across three or four vendor consoles.
SOC 2	Common Criteria CC7.1 (detection of system anomalies), CC7.2 (security event analysis), CC7.3 (incident response), CC7.4 (vulnerability remediation), and CC9 (vendor and configuration management) expect documented detection, response, and closure across the cloud estate. The engagement record produces the trail in one place so the SOC 2 lookback reads the cloud posture as a derivable property rather than as a multi-tool reconciliation sprint.
PCI DSS 4.0	Requirements 6 (developing and maintaining secure systems and software), 11.3 (vulnerability identification and prioritisation), and 12.3.1 (risk assessment) expect cloud-resident misconfigurations to be tracked, severity-rated, owner-routed, and remediated on a defined timeline with documented exception handling. The engagement record produces the named-owner evidence and the SLA evidence assessors read against the cloud estate that handles cardholder data.
NIS2 and DORA (EU regulatory)	NIS2 vulnerability handling (Article 21) and DORA ICT risk management (Articles 6 to 9 and 17 to 22) expect documented detection, remediation timeline, exception handling, and supplier-side cloud configuration evidence. The CSPM finding remediation workflow produces the regulator-facing evidence (registry of detections, remediation cadence, exception register, supplier coverage) on the engagement record rather than from a vendor-managed dashboard the regulator cannot access at scale.

Where CSPM finding remediation sits in the wider security programme

The workflow composes with the rest of the security programme on the same engagement record so the cloud posture layer stays connected to the per-finding, per-control, and per-release work that runs alongside it.

Upstream and adjacent

CSPM finding remediation depends on cloud security assessment for the broader programme, asset criticality scoring for the tier decision, asset ownership mapping for the named owner, scanner result triage for the per-detection lifecycle inside the cloud posture queue, container image vulnerability remediation for the workload-tier findings that compose with cloud misconfigurations, and vulnerability finding merge and supersede for the deduplication discipline against IaC scans and external scan signals.

Downstream and reporting

CSPM evidence rolls into remediation tracking for the per-finding closure narrative, vulnerability acceptance and exception management for the structured exception flow, vulnerability SLA management for the time-bound resolution discipline, control mapping cross-framework crosswalks for the framework evidence package, security leadership reporting for the cadence that reads cloud posture as a leading indicator, and audit evidence retention and disposal for the long-tail evidence chain.

Pair the workflow with the long-form guides and the framework references

The CSPM remediation workflow is operational; the surrounding guides explain the category, the assessment context, and the framework expectations the workflow has to satisfy. Pair this workflow with the cloud security posture management explainer for the category background, the cloud security assessment guide for the wider assessment programme, SSPM and KSPM for the adjacent posture categories, and the continuous threat exposure management explainer for the broader exposure model the cloud posture programme operates inside. The framework references that mandate cloud-resident misconfiguration tracking and remediation evidence include ISO 27017 for cloud-specific controls, CSA Cloud Controls Matrix for the cloud control domain set, NIST SP 800-53 for the CM, SI, AC, and AU control families, SOC 2 for the CC7 and CC9 Common Criteria, PCI DSS for cardholder-data cloud surface, and DORA for the EU ICT third-party and cloud-resident requirements.

Buyer and operator pairing

The CSPM finding remediation workflow is the workspace cloud security teams run as the operational spine for cloud misconfiguration findings, security engineering teams run alongside as the platform-side runtime owners, AppSec teams run when application-tier findings overlap with cloud misconfigurations, vulnerability management teams run for SLA discipline and the leadership posture read, and GRC and compliance teams run for the framework mapping and audit evidence package. CISOs read cloud posture coverage, remediation velocity, exception register, and severity recalibration as leading indicators of whether the cloud security programme is reducing real exposure or just generating dashboards.

What a healthy CSPM finding remediation programme feels like

Ingestion is structured, not a CSV pivot

CSPM exports land on the engagement record through bulk finding import with column mapping autodetection. The cloud team triages from the engagement view rather than from the vendor console, and the lifecycle starts on a structured record from day one rather than from a raw CSV the analyst pivots in Excel.

Deduplication is a query, not a guess

Cross-engagement finding search surfaces duplicate candidates against prior cycles and adjacent sources (IaC scans, external scans, manual review) before the team starts triaging. One identity per underlying misconfiguration across CSPM cycles, IaC stages, and external scan signals.

Exceptions expire instead of accumulate

Suppressions ride on the structured finding overrides workflow with cited reason, named approver, target resource scope, and expiry date. The next CSPM ingestion inherits the decision so suppressions stop accumulating silently inside the vendor console.

Evidence is derivative of the work

Cloud posture trend, remediation velocity, exception register, severity recalibration trail, and framework coverage derive from the live engagement record. The activity log export is the trail and the AI report is the narrative. Nobody assembles cloud posture evidence the week before the audit.

CSPM finding remediation is the operational layer between cloud detection tools and the audit. Run the workflow on the engagement record so ingestion is structured rather than a CSV pivot, deduplication is a query rather than a guess, severity is calibrated against runtime exposure rather than left at the vendor default, exceptions expire rather than accumulate, fixes verify through retest evidence rather than auto-close, and the leadership posture read derives from the live record rather than from a parallel vendor extract. For the upstream scanner integration that feeds the workflow, pair this page with the scanner result triage workflow; for the structured exception flow the workflow depends on, pair it with the vulnerability acceptance and exception management workflow; and for the leadership cadence that reads cloud posture as a leading indicator, pair it with the security leadership reporting workflow.

Frequently asked questions about the CSPM finding remediation workflow

What is a CSPM finding remediation workflow?

A CSPM finding remediation workflow is the operational lifecycle that takes a cloud security posture management detection from intake to verified closure on a single shared record. The lifecycle covers ingestion from the CSPM tool, deduplication against prior cycles and adjacent sources (IaC scanning, external scanning, manual review), severity recalibration against runtime exposure, owner routing on a named SLA tier, structured exception handling with expiry, retest verification with cited evidence, and audit-ready evidence assembly. The discipline turns CSPM exports into operational work rather than letting findings age inside the vendor console.

How is this workflow different from cloud security posture management (CSPM)?

CSPM is the detection layer: rules that scan cloud configurations against known control standards and surface misconfigurations as findings. The remediation workflow is the operational layer that runs on top: how the workspace ingests CSPM detections, reconciles them against duplicate sources, calibrates severity against real exposure, routes findings to named owners, holds exceptions to an expiry date, and verifies fixes with cited evidence. CSPM produces detections; the remediation workflow produces closures the audit can read. Both layers compose. CSPM is the rule pack; the workflow is the contract the team runs against.

Does SecPortal replace a CSPM tool like Wiz, Prisma Cloud, or Defender for Cloud?

No. SecPortal is the operational layer between the CSPM detection engine and the audit. It ingests CSPM exports through bulk finding import, runs the deduplication, severity calibration, routing, exception, and verification workflow on the engagement record, and produces the audit-ready evidence trail. The CSPM tool keeps producing detections; the workspace keeps the closure narrative, the exception register, and the leadership-facing posture read. Many teams operate with a CNAPP for detection alongside SecPortal for the operational workflow because the two solve different problems.

How does this handle multi-account and multi-cloud estates?

Open one engagement per cloud account, subscription, project, or business-unit boundary depending on how the cloud organisation is structured. For a hub-and-spoke setup with hundreds of accounts, group accounts under the business owner so the engagement granularity matches the actual owner map rather than mirroring the account topology. Each engagement holds the CSPM source, the framework mapping, the named owner, and the SLA tier. The workspace findings view aggregates across engagements so leadership can read cloud posture as a single estate-wide number while operations still routes per account.

How are CSPM exceptions handled without ad-hoc suppressions?

Use the structured finding overrides workflow rather than suppressing findings inside the CSPM console. The override carries the cited reason (false positive, accepted risk, severity override), the named approver, the targeted resource scope, the compensating controls, and a documented expiry date. The override applies on the next CSPM ingestion cycle so the next scan inherits the decision rather than re-creating the duplicate on the open queue. Verbal Slack approvals do not survive the audit lookback because they never landed on the record. Read the vulnerability acceptance and exception management workflow for the full pattern.

How do IaC scanner findings and runtime CSPM findings reconcile?

Open one engagement per cloud account or business-unit boundary and route IaC scanner detections, runtime CSPM detections, and external scan signals against cloud endpoints to that same engagement. When the IaC scanner finds a misconfiguration in a Terraform module and the CSPM finds the same misconfiguration on the deployed resource three days later, the cross-engagement finding search surfaces the candidate duplicate and the merge convention consolidates them into one identity. The closure narrative captures the upstream IaC fix and the runtime verification on the same record so the audit reads the full lifecycle.

How does AI report generation summarise cloud posture?

AI report generation derives the cloud posture narrative from the live engagement record: open finding count by severity, by account, by control reference, and by named owner; remediation velocity by month; exception register and approaching expirations; severity recalibration trail tied to documented compensating controls; retest verification cadence; framework mapping coverage. The named approver edits the draft instead of writing from a blank page, and the headline figure always reconciles to the underlying record because the report is generated from the same record the cloud team operates against.

What about ephemeral cloud resources that come and go between scans?

Short-lived resources (autoscaling instances, ephemeral build runners, on-demand Kubernetes pods, preview environments) need a separate convention from durable resources. Tag short-lived resources at provision time so the CSPM ingestion can recognise the lifecycle. A finding on an ephemeral resource that has already retired closes as not_applicable with the resource lifecycle as the cited reason rather than aging on the open queue forever. The asset decommissioning and finding retirement workflow handles the retirement evidence so closure on ephemeral resources is auditable rather than implicit.

How does this workflow support audit evidence and compliance reads?

The engagement record holds the cloud account boundary, the framework mapping, the named owner, the calibrated severity, the structured exception trail, the retest verification, and the activity-log entry for every state change. The activity log export is the trail behind the headline numbers and covers ISO 27017 cloud controls, CSA CCM domains, NIST 800-53 CM and SI families, SOC 2 CC7 and CC9, PCI DSS Requirements 6 and 11, and NIS2 or DORA cloud-resident expectations by deriving the evidence from the record rather than collecting it before each audit cycle.

Who runs this workflow inside a typical enterprise security team?

The cloud security team or cloud platform team owns the cloud account engagements and the routing decisions. AppSec owns the verdict on application-tier cloud findings. The vulnerability management team owns the SLA discipline and the leadership posture read. GRC owns the framework mapping, the exception register, and the audit evidence package. The CISO reads the live engagement record rather than a hand-assembled scorecard. The workflow runs on a shared record so the four functions write the contract together instead of reconciling four parallel views.

How it works in SecPortal

A streamlined workflow from start to finish.

Open the cloud account as an engagement and register the asset boundary

Create one engagement per cloud account, subscription, project, or organisation unit (or per business unit when several accounts roll up to the same owner). Record the cloud provider, the account or subscription identifier, the named owning team, the criticality tier, the in-scope service surface, the CSPM source that produces the findings, and the framework set the account has to map against. Registration is the contract; the engagement record is the surface every CSPM finding lands on rather than a sprawl across consoles.

Ingest CSPM and cloud scanner findings onto the engagement

Export CSPM findings as CSV from the source (Wiz, Prisma Cloud, Defender for Cloud, AWS Security Hub, Tenable Cloud Security, Orca, native cloud scanners) and ingest through bulk finding import with column mapping autodetection. Map cloud resource id, region, account id, control reference, and detection timestamp onto the finding record. The engagement record collects the cloud posture rather than depending on whichever console is logged in this week.

Deduplicate against prior cycles and recognise scanner-artefact false positives

Run cross-engagement finding search against the workspace history to surface candidate duplicates from a prior CSPM run, an external pentest, or a manual review. Recognise scanner-artefact false positives (a control reference that fires on a resource the policy explicitly allows, a stale resource the inventory has not retired, a multi-account misattribution) and consolidate the surviving record on the active engagement. The merge convention is in the vulnerability finding merge and supersede workflow; pair it with this lifecycle so cloud findings stay identity-coherent.

Calibrate severity against real cloud exposure, not the CSPM default

CSPM defaults rate every public S3 bucket the same; the real exposure depends on whether the bucket holds production customer data, whether identity controls compensate, whether the account is internet-reachable, and whether the resource is in scope for a regulatory boundary. Recalibrate severity with CVSS 3.1 against the runtime context and record the rationale on the finding so the audit lookback reads the calibration as a named decision rather than as drift. Severity is a state event with timestamp and user attribution rather than an editable label.

Route findings to the named cloud account owner and remediation SLA tier

Findings inherit the named owner and the SLA tier from the engagement registration. Critical and high cloud misconfigurations route to the platform or cloud engineering owner with the cited remediation guidance and the targeted resolution date. Notifications fan out to per-user inboxes so the owner sees the assignment without polling the activity log. Open findings without a named owner are themselves a defect; the workflow surfaces them as a known gap rather than letting them age silently.

Capture structured exceptions and recurring suppressions on the record

When remediation is deferred or a finding is a documented false positive the team has previously dismissed, write the override with the cited reason (false positive, accepted risk, severity override), the named approver, the targeted resource scope, and a documented expiry date. The override carries the decision forward on the next CSPM ingestion so the next cycle inherits the suppression rather than re-creating the duplicate on the open queue. Verbal approvals do not survive the audit lookback.

Verify fixes through retest evidence rather than CSPM auto-close

When the cloud team applies the remediation (rotate the credential, lock down the bucket policy, attach the SCP, enable the KMS key rotation, restrict the security group), move the finding to resolved with the cited fix evidence. Re-run the CSPM scan or import the next cycle export and move the finding to verified only after the absence of the detection is confirmed. Reopen the original record if a regression detection lands on a future scan so the closure history stays on one record across cycles.

Produce audit-ready evidence and the leadership posture read

AI report generation derives the cloud posture narrative from the live engagement record: open finding count by severity, account, and control reference; remediation velocity; exception register and expiry posture; severity recalibration trail; retest verification cadence. The activity log export is the trail behind the headline numbers. The leadership cadence reads cloud posture as a derivable property of the record rather than a screenshot of whichever CSPM console the team logged into that morning.

Features that power this workflow

Orchestrate every security engagement from start to finish

Vulnerability management software that tracks every finding

Bulk finding import bring your scanner data with you

Finding overrides that survive every scan cycle

Vulnerability scanning tools that map your attack surface

Test web apps behind the login

Monitor continuously catch regressions early

Document management for every security engagement

Every action recorded across the workspace

AI-powered reports in seconds, not days

Collaborate across your entire team

Multi-factor authentication on every workspace

Verify fixes and track reopens on the same finding record

Compliance tracking without a full GRC platform

Notifications and alerts for the people who carry the work

Run cloud misconfiguration findings on one engagement record

Ingest CSPM exports, deduplicate against history, calibrate severity against real exposure, route to the named owner, hold exceptions to an expiry date, and verify fixes through retest evidence. Start free.