Cloud Detection and Response (CDR): Explained
Cloud Detection and Response (CDR) is the security technology category that ingests cloud-native telemetry (control-plane audit logs, identity-plane events, data-plane access logs, workload runtime signal, network flow logs, and cloud-provider security signals), applies behavioural and signature analytics on top of that record, and exposes investigation and response workflows that act on detected cloud activity. For CISOs, cloud security teams, security operations leaders, SOC analysts, detection engineers, AppSec leads, vulnerability management owners, and GRC partners, CDR is the operating discipline that turns the cloud audit log surface itself into a reviewable detection record with a named evidence trail. This guide covers what CDR is and is not, the five capability layers (Cloud Telemetry, Behavioural Analytics, Detection Engineering, Investigation and Response, Evidence and Reporting), how CDR differs from CWPP, CSPM, CNAPP, CIEM, KSPM, EDR, XDR, NDR, MDR, SIEM, SOAR, and ITDR, the cloud-native attack patterns that drive the category, the recurring adoption pitfalls, the onboarding shape that bounds MTTD, and how the finding side of the CDR record connects to prioritisation, remediation tracking, and CTEM so the detection work does not live in a parallel cloud backlog.
What CDR Actually Is
Cloud Detection and Response is a technology category and an operating model. The platform ingests cloud-native telemetry (control-plane audit logs, identity-plane events, data-plane access logs, workload runtime signal from agent or eBPF probe, network flow logs, and the per-provider security signals such as GuardDuty, Defender for Cloud, and Security Command Center), applies behavioural analytics and signature analytics on top of that record, and exposes investigation and response workflows that act on detected cloud activity. The defining property is the cloud-native telemetry source. CDR reasons about what is happening on the cloud control plane (API calls to provision, modify, or read resources), the identity plane (token issuance, role assumption, privileged operations, IMDS-derived credentials), the data plane (object reads and writes, database queries, secret access), and the workload plane (process execution, container behaviour, serverless invocation) rather than what an endpoint agent on a workstation or a sensor on a corporate network would observe.
The category emerged in the early 2020s as cloud adoption matured past the configuration-only posture that CSPM covers and past the workload-runtime posture that CWPP covers. Attackers moved from exploiting misconfigured resources directly to abusing legitimate cloud identities, role chains, and API surfaces. The configuration-side controls hardened the static state; the workload-side controls hardened the running instance; the detection-side category that watches the active cloud control plane, the identity plane, and the data plane was the missing layer. CDR is the packaging that puts cloud telemetry on the same operating shape EDR introduced for the endpoint, NDR for the network, and ITDR for the identity provider: a record on the audit log surface, an investigation surface, and a defined response set.
CDR is a technology category rather than a service. A buyer can run CDR with an internal cloud SOC and no external analyst provider, or pair CDR with an MDR provider that supplies 24x7 analyst capacity above the cloud detection stack. The mature programme distinguishes between the platform decision (which CDR engine we operate, against which clouds, against which accounts) and the staffing decision (who staffs the cloud detection seat). The two are commonly bought separately and integrated by the customer, with the platform decision driving telemetry topology and the staffing decision driving operating shape.
The Five Capability Layers of a CDR Platform
A mature CDR platform has five capability layers. The layers depend on each other: a gap in any of them weakens the service the platform produces. Buyers evaluating CDR vendors should benchmark each layer against the named cloud accounts, the named detection content, the named response actions, and the named outcome metrics the programme actually needs, rather than treating the CDR category label as a capability claim.
Layer 1: Cloud Telemetry
Cloud Telemetry covers the cloud-native signal sources the platform ingests natively and the per-account, per-region coverage map. The minimum viable CDR footprint is control-plane audit log coverage across every production account (CloudTrail multi-region trails with data events on critical buckets, Azure Activity Log diagnostic settings, GCP Cloud Audit Logs across Admin Activity, Data Access, and System Event log types) plus the cloud-provider native security signal (GuardDuty, Defender for Cloud, Security Command Center). A stronger platform also ingests identity- plane events (federation events, role assumptions, token issuance, service principal usage, managed identity calls), data-plane access logs (S3 access logs, Azure Storage diagnostic logs, GCP logging on data services, database audit logs, secret access logs from KMS, Key Vault, and Cloud KMS), workload runtime signal from an agent or eBPF probe inside the workload, and cloud network flow logs (VPC Flow Logs, NSG Flow Logs, GCP Flow Logs). Buyers should benchmark per-account coverage against the cloud-account inventory the organisation actually operates. A platform that only ingests CloudTrail Admin Activity events produces detection with a structural blind spot on data-plane abuse.
Layer 2: Behavioural Analytics
Behavioural Analytics is the layer that learns what normal cloud activity looks like per identity, per role, per region, per service, and per workload class, so deviations surface even when no signature exists for the specific attacker tradecraft. The analytics build baselines across many dimensions: which identities normally call which APIs, which roles are assumed from which addresses at which times, which workloads normally access which data services, which regions are normal for which identity, which API call volumes are normal for which service principal. The platform raises an alert when observed activity deviates from the baseline in a way that fits an attacker profile (an identity that suddenly lists every bucket from an address it has never used, a role that is assumed at an unusual time from an unfederated origin, a workload that begins enumerating IAM resources, a managed identity that starts calling APIs outside its normal workload pattern). The behavioural layer is what makes CDR catch attacker tradecraft that uses legitimate cloud APIs in anomalous patterns.
Layer 3: Detection Engineering
Detection Engineering covers the vendor-maintained library of cloud-specific detections, mapped against the MITRE ATT&CK Cloud Matrix techniques and per-cloud-provider sub-techniques, the customer-side tuning surface, the rule-update cadence as cloud-provider feature releases create new attack surfaces, and the testing harness that validates detections survive cloud-provider API changes. Mature platforms cover the seven recurring cloud-attack patterns (cloud credential theft and abuse, IMDS abuse and instance role pivot, role chain escalation, resource enumeration and reconnaissance, data exfiltration through legitimate APIs, persistence through cloud configuration, and resource abuse including cryptomining) and ship detection content for each pattern on each major cloud provider. Detection Engineering is also where the platform distinguishes between a library shipped from the vendor and a library tuned to the customer baseline. A library that fires on every legitimate deployment automation produces alert fatigue; a library tuned to the customer normal operating shape produces high-confidence signal. The internal detection engineering function on the customer side still owns the carve-outs, the custom rules, the suppression set, and the tuning backlog regardless of how strong the vendor library is.
Layer 4: Investigation and Response
Investigation and Response covers the analyst workflow (cloud timeline reconstruction across CloudTrail, identity provider, and data-plane logs; identity and resource pivoting; attack-chain visualisation; evidence retrieval and preservation) and the response action set the platform executes. The minimum response set is detection-only with handoff to other tools. Stronger platforms execute cloud- side actions directly: IAM user disable, access key deactivation, role detach, session revocation through STS or equivalent, workload quarantine via security group change, instance isolation through subnet move, key rotation trigger through KMS or Key Vault, suspicious resource snapshot for forensics, and managed identity deactivation. Tighter platforms also coordinate with identity providers (account disable, session revocation at the IdP), endpoint (host isolation via EDR), and network (firewall rule push, WAF rule push) response surfaces. The response set is documented in the customer runbook with named carve-outs for production identities, workloads, and accounts the platform cannot touch without explicit approval. Platforms with strong detection but weak response leave the analyst to pivot into provider consoles for execution and stretch MTTR.
Layer 5: Evidence and Reporting
Evidence and Reporting covers the per-incident record, the executive cadence read, and the audit-grade output the customer reads at framework audit and at cyber insurance renewal. The per-incident record names the telemetry source (which audit log on which account in which region), the detection rationale (which behavioural baseline or signature fired, against which identity, against which resource, with which MITRE ATT&CK Cloud Matrix technique mapping), the investigation finding, the response action, the identity and resource touched, the log excerpt the evidence depends on, and the closure rationale. The executive cadence read covers MTTD, MTTR, MTTC, account and region coverage, cloud identity coverage ratio, false positive rate, and closed-loop verification rate cycle-on- cycle. The audit-grade output maps incident-level evidence against ISO 27001 Annex A 8.16, A.5.23, A.5.30, and A.8.20, SOC 2 CC7.2 and CC7.3, PCI DSS Requirement 10 and 11.5, NIST 800-53 SI-4, AU-2, AU-12, and SC-7, NIST CSF 2.0 DE.AE and DE.CM, and ISO/IEC 27017 cloud-specific controls so the CDR platform produces directly defensible audit material rather than only a vendor dashboard.
CDR vs CWPP, CSPM, CNAPP, CIEM, KSPM, EDR, XDR, NDR, MDR, SIEM, SOAR, and ITDR
CDR overlaps with several adjacent categories. The boundaries are operational rather than strict, and mature cloud security programmes run more than one in parallel. The table below lays out the differences so security leaders can decide what each category actually buys them and where CDR sits relative to the existing security stack.
| Category | Anchor | Relationship to CDR |
|---|---|---|
| CWPP | Cloud Workload Protection Platform: image scanning, vulnerability scanning at the running instance, host hardening, file integrity, workload-side runtime detection. | Different telemetry source. CWPP sees what runs inside a workload; CDR sees what happens on the cloud control, identity, and data planes around it. Complementary. |
| CSPM | Cloud Security Posture Management: configuration state assessment of cloud-account resources against a baseline such as CIS Benchmarks. | CSPM tells the team a bucket is public; CDR tells the team an unusual identity just read a thousand objects from it. Configuration vs active behaviour. Complementary. |
| CNAPP | Cloud-Native Application Protection Platform: consolidating umbrella across CSPM, CWPP, CIEM, KSPM, and increasingly CDR with cross-signal correlation. | CDR is one of the sub-disciplines CNAPP consolidates. CNAPP correlates CDR detections against configuration, workload posture, identity entitlement, and Kubernetes posture in one surface. |
| CIEM | Cloud Infrastructure Entitlement Management: static analysis of cloud-account permissions to identify over-privilege and unused entitlement. | CIEM identifies the privilege model that CDR detections operate against. CIEM hardens the privilege surface in advance; CDR detects active abuse of whichever privileges remain. |
| KSPM | Kubernetes Security Posture Management: configuration state assessment of Kubernetes clusters, workloads, and policies. | KSPM is the Kubernetes-specific configuration layer below the cloud account. CDR detection on Kubernetes audit logs and admission events overlaps with KSPM detection content; KSPM remains the configuration-state pair. |
| EDR | Endpoint Detection and Response: agent on workstations and laptops observing process, file, registry, and memory activity. | EDR sees what a user is doing on a corporate laptop; CDR sees what an identity is doing inside the cloud account. Credential theft is EDR; credential abuse from anomalous origin is CDR. |
| XDR | Extended Detection and Response: unified platform across endpoint, network, cloud, identity, and email with cross-source correlation. | CDR is the cloud slice. XDR is the umbrella. XDR either subsumes CDR natively or integrates a best-of-breed CDR product and reasons about its signals alongside EDR, NDR, identity, and email. |
| NDR | Network Detection and Response: behavioural analytics on network telemetry including some cloud-network flow logs. | NDR observes the wire; CDR observes the cloud control plane, identity plane, and data plane. Overlap on cloud network flow logs; each retains its own telemetry depth. |
| MDR | Managed Detection and Response: service category in which a provider runs 24x7 analyst capacity above a telemetry stack. | CDR is the technology. MDR is the staffing. Pairing pattern: CDR engine plus MDR analysts above it for organisations that cannot run a 24x7 internal cloud SOC. |
| SIEM | Security Information and Event Management: general-purpose telemetry collection, normalisation, correlation, and search platform. | Cloud audit logs are a common SIEM source. SIEM gives long-tail log retention and custom content; CDR gives cloud-specific behavioural analytics and a named cloud response surface. |
| SOAR | Security Orchestration, Automation, and Response: scripts response actions and ticket flows across the security stack. | CDR is one detection source SOAR reads from. SOAR orchestrates the response playbook; modern CDR ships built-in response actions for the cloud surface specifically. |
| ITDR | Identity Threat Detection and Response: identity provider, session, and privileged access telemetry. | Overlap on cloud identity. ITDR focuses on the identity provider surface; CDR covers federated SSO into cloud accounts, role chains, service principals, managed identities, and IMDS-derived credentials. |
CDR is not a replacement for any of these. A programme that operates a strong SIEM for long-tail log retention, a dedicated EDR product for endpoint depth, a CWPP for workload-runtime posture, a CSPM for cloud configuration hygiene, a CIEM for cloud privilege analysis, an ITDR layer for identity, a SOAR platform for cross-system orchestration, and a CAASM record for inventory has many tools but lacks the cloud-side behavioural detection layer that CDR contributes. A programme that ships CDR as a replacement for any of these usually loses depth on one or more surfaces and ends up reintegrating the dedicated tools later.
The label distinction also matters at procurement. Some vendors marketing themselves as CDR ship a CloudTrail dashboard with weak behavioural analytics. Others ship strong cloud-side behavioural analytics with limited response surface. Buyers evaluating CDR vendors should benchmark the five capability layers, the per-account and per-cloud coverage map, the named detection content per cloud provider, the named response actions per surface, and the named outcome metrics, rather than treating the CDR category label as a capability claim. A coverage matrix that names the in-scope cloud accounts, the detection content per provider, and the response authority per cloud surface is the procurement artefact that separates a programme-grade platform from a CloudTrail subscription.
Cloud Telemetry: Where CDR Sees
CDR is only as good as its telemetry topology. A platform with strong analytics and incomplete telemetry produces detection with structural blind spots that the programme will not see until an incident traverses one of them. Buyers should plan the telemetry topology against the cloud-account inventory and revisit it cycle-on-cycle as the cloud estate evolves.
Control plane (audit logs)
Control-plane audit logs record every API call against the cloud account: CloudTrail on AWS, Azure Activity Log on Azure, Cloud Audit Logs on GCP. The minimum CDR footprint covers the management-event tier across all accounts and regions with multi-region trails configured. Stronger coverage adds data events on critical buckets, queues, topics, function invocations, and equivalent surfaces on each provider. Control-plane logs are the primary surface for resource enumeration detection, persistence detection (new IAM user, modified Lambda role, replaced EventBridge rule), and provisioning anomaly detection. Programmes that enable logging in production accounts but skip sandbox and research accounts produce blind spots on the accounts attackers most often pivot through.
Identity plane (federation, role, token)
Identity-plane events record federation events from the identity provider into the cloud account, STS or equivalent role-assumption events, token issuance, service principal usage, and managed identity calls. These records surface the role-chain escalation patterns, anomalous federation from unexpected addresses, dormant service principals returning to activity, and managed identities calling APIs outside their normal workload pattern. The identity plane is where most modern cloud attacks land because attackers prefer abusing legitimate identities over exploiting misconfigured resources.
Data plane (object, database, secret)
Data-plane access logs record reads and writes on data services: S3 server access logs, Azure Storage diagnostic logs, GCP Cloud Logging on data services, database audit logs, secret access logs from KMS, Key Vault, and Cloud KMS. Data-plane signal is what catches data exfiltration through legitimate APIs (object copy to attacker-controlled bucket, snapshot share to attacker account, database export to staging environment, replication configuration that mirrors to an unauthorised destination). Programmes that enable control-plane logging but skip data-plane logging on critical buckets pay the cost at the moment of exfiltration: the resource enumeration is in CloudTrail, but the actual data movement is not.
Workload plane (runtime signal)
Workload runtime signal comes from an agent or eBPF probe inside the workload: process trees, syscalls, file events, container behaviour, serverless invocation context. This layer overlaps with CWPP and many CDR platforms either ship the workload agent themselves or integrate with a CWPP product to read its runtime signal. Workload signal is what catches IMDS abuse (the workload process that calls the metadata service for role credentials), cryptomining (unexpected processes consuming CPU), and reverse shell or persistence on the workload itself.
Network plane (cloud flow logs)
Cloud network flow logs (VPC Flow Logs, NSG Flow Logs, GCP Flow Logs) record traffic between cloud resources and to or from the internet. The signal is metadata-only (source, destination, port, byte count, packet count) and resembles what NDR consumes on the corporate network. Cloud flow logs are the primary surface for cross-region traffic anomalies, internal lateral movement between workloads, outbound exfiltration to an attacker-controlled destination, and the cross-account traffic patterns that shared services produce.
Cloud-provider security signals
Cloud-provider native security signals (AWS GuardDuty, Azure Defender for Cloud, GCP Security Command Center Premium) ship with built-in threat intelligence, known bad-actor IP feeds, anomaly detection on standard control-plane patterns, and provider-specific signal (RDS protection findings, EKS audit log analysis, S3 anomalous access patterns). CDR platforms typically ingest these signals as one source among many rather than replacing them. Treating the provider native signal as a complete CDR programme overlooks cross-account correlation, custom detection content, the consolidated response surface, and the cross-provider operating record that a multi-cloud programme needs.
Cloud-Native Attack Patterns CDR Detects
Seven recurring attack patterns drive the CDR category and inform the per-cloud detection content libraries. Each pattern maps to MITRE ATT&CK Cloud Matrix techniques and to specific telemetry sources on each cloud provider.
1. Cloud credential theft and abuse
Stolen long-lived access keys, leaked OIDC tokens from CI/CD pipelines, or stolen session credentials from workstation compromise used to reach cloud APIs from anomalous origins. The detection pattern is identity used from a new address, new user agent, or new region; or identity used outside normal hours; or identity used with API call patterns it has never produced before. MITRE ATT&CK Cloud techniques include T1078.004 (Valid Accounts: Cloud Accounts) and T1552 (Unsecured Credentials).
2. IMDS abuse and instance role pivot
Attacker on a compromised workload calls the instance metadata service (IMDSv1 or misconfigured IMDSv2) to obtain the workload role credential, then pivots to broader cloud resources using that role. The detection pattern is the workload role being used from an external address, or being used to call APIs the workload never calls in normal operation. MITRE ATT&CK Cloud techniques include T1552.005 (Unsecured Credentials: Cloud Instance Metadata API).
3. Role chain escalation
Attacker assumes a series of cross-account or cross- service roles to escalate from low privilege to administrative reach, often through sts:AssumeRole chains or service-linked roles. The detection pattern is an unusual role-assumption sequence, role assumption from a new principal, or role assumption that crosses an account boundary the identity has not crossed before. MITRE ATT&CK Cloud techniques include T1078 (Valid Accounts) and T1098 (Account Manipulation).
4. Resource enumeration and reconnaissance
Anomalous ListBuckets, DescribeInstances, ListRoles, or equivalent enumeration calls from a non-typical identity, often as the first stage of cloud-side reconnaissance after initial access. The detection pattern is high-volume read API calls from an identity that does not normally produce them. MITRE ATT&CK Cloud techniques include T1580 (Cloud Infrastructure Discovery) and T1538 (Cloud Service Dashboard).
5. Data exfiltration through legitimate APIs
Object copy to attacker-controlled bucket, snapshot share to attacker account, database export to staging environment, or replication configuration that mirrors to an unauthorised destination. The detection pattern is data movement crossing an account boundary or writing to a destination outside the documented replication topology. MITRE ATT&CK Cloud techniques include T1537 (Transfer Data to Cloud Account) and T1567 (Exfiltration Over Web Service).
6. Persistence through cloud configuration
Attacker adds a backdoor IAM user, modifies a Lambda execution role, replaces an EventBridge rule, registers a new service principal, modifies a trust policy, or creates a federation provider that retains access after the original compromise vector is cleaned. The detection pattern is privilege change, identity creation, or trust-policy modification outside the normal provisioning automation pattern. MITRE ATT&CK Cloud techniques include T1098 (Account Manipulation), T1136 (Create Account), and T1556 (Modify Authentication Process).
7. Resource abuse and cryptomining
Attacker spins up compute, enables expensive services, or scales workloads beyond programme baseline; often cryptomining or relay infrastructure for further attacks. The detection pattern is RunInstances or equivalent calls outside normal regions or instance types, cost anomaly on the billing surface, or unexpected processes consuming CPU inside running workloads. MITRE ATT&CK Cloud techniques include T1496 (Resource Hijacking).
CDR Onboarding: Five Stages
A defensible CDR onboarding has five stages and runs typically four to twelve weeks depending on cloud-account count, region count, and the number of identity-federation surfaces being instrumented. The discipline is to invest in the baseline period up front so steady-state alert quality is bounded rather than only promised.
Stage 1: Telemetry enablement
Turn on per-account audit logging across CloudTrail multi-region trails with data events on critical buckets, Azure Activity Log diagnostic settings, and GCP Cloud Audit Logs across Admin Activity, Data Access, and System Event log types. Ensure logs flow to the platform. Validate per-region and per-account coverage against the cloud-account inventory. Enable the cloud-provider native security signal (GuardDuty, Defender for Cloud, Security Command Center) if not already enabled and route to the platform.
Stage 2: Scope definition
Document the account criticality tiers (production, staging, sandbox, research). Document the environments in scope and the data classes resident in each account. Document the named contacts per account. Document the carve-outs for sandbox and research accounts where detections may still ingest but response actions are inhibited. Document the response authority chain per account class.
Stage 3: Baseline learning
Run the platform against the cloud baseline for two to four weeks so the behavioural analytics layer learns what normal looks like per identity, per role, per region, per service, and per workload class. Resist enabling auto-response during baseline learning. Capture the baseline distributions so later drift is detectable as a distribution shift rather than as one alert.
Stage 4: Detection tuning
Identify and suppress noisy legitimate signal (deployment automation that scales beyond baseline, scheduled backup jobs that copy data across regions, normal IAM provisioning by the platform team, regular cross-account replication for analytics, expected Terraform provisioning bursts). Tune the vendor detection library to the customer environment. Resolve false positives the baseline period surfaced.
Stage 5: Response calibration
Walk the named response actions (IAM user disable, access key deactivation, role detach, session revocation, workload quarantine via security group change, key rotation trigger, account isolation). Document the named approval thresholds (auto vs notify-then-act vs customer-approval-required). Document the escalation tree. Document the carve- outs for production identities, workloads, and accounts the platform cannot touch without explicit approval. Test the response actions against a non- production target to validate the runbook before an incident requires it.
Adoption Pitfalls
Seven recurring failure modes appear in CDR rollouts. Each shows in the per-incident record and the executive cadence read before it shows in the leadership report.
1. CloudTrail dashboard treated as detection
Cloud-provider audit logs are telemetry, not detection. A dashboard with raw events and no behavioural analytics, no per-identity baseline, no tuned detection content, and no defined response surface is the most common starting point and the most common ceiling. The dashboard tells the team what happened; CDR tells the team what was unusual about what happened.
2. Production-only logging
Enabling logging in production accounts but skipping sandbox and research accounts produces blind spots on the accounts attackers most often pivot through. Sandbox accounts often have weaker controls, broader privileges, and connections back to production. Detection coverage across every account in the organisation is the discipline that closes the pivot path.
3. Provider native treated as complete
GuardDuty, Defender for Cloud, and Security Command Center are strong signal sources but do not by themselves constitute a CDR programme. They lack cross-account correlation, custom detection content, the consolidated response surface, and the cross- provider operating record a multi-cloud programme needs. CDR ingests these signals as one source among many; treating them as a complete programme leaves the operating discipline incomplete.
4. Baseline period skipped
Skipping the baseline period produces alert fatigue in the first month because behavioural analytics fires on every legitimate deployment automation. The discipline is to invest two to four weeks in baseline learning before enabling auto-response so the steady-state alert quality is bounded rather than only promised.
5. Auto-response without carve-outs
Granting response authority without explicit carve- outs produces operational incidents when the platform disables a production identity during a deployment window, isolates a workload running a critical batch job, or rotates a key referenced by a deployed application. The named carve-outs go in the runbook with the response calibration stage of onboarding.
6. Parallel cloud backlog
Reading detections in the vendor console without ingesting validated incidents into the wider security finding queue creates a parallel cloud backlog that does not collapse into the audit-read record. Programmes that hold CDR output in the vendor console separate from the wider finding queue have to reconcile two records at audit; programmes that ingest CDR-validated incidents into the same finding record as scanner output, pentest findings, and bug bounty submissions collapse the audit read and the prioritisation backlog into one source.
7. CDR as substitute
Treating CDR as a substitute for the configuration- side CSPM programme or the workload-side CWPP programme misses the layered defence the categories are designed to deliver together. CSPM identifies the misconfiguration that the attacker reaches; CWPP detects compromise of the running workload; CDR detects abuse of the cloud control plane, identity plane, and data plane. The three are complementary; running one alone produces a thinner defence than the cost suggests.
CDR Programme Metrics
Seven metrics make the CDR programme reviewable cycle-on- cycle and connect the operational record to the leadership read. Reporting these alongside the inflow-and-closure trend gives leadership the detection question, the bottleneck identification, and the coverage signal on one record.
| Metric | What it measures |
|---|---|
| MTTD | Mean Time to Detect: time from the malicious cloud activity to the validated CDR alert. |
| MTTR | Mean Time to Respond: time from the alert to the response action. |
| MTTC | Mean Time to Contain: time from the alert to the containment outcome that stops impact from spreading across the cloud account. |
| Account and region coverage | Proportion of cloud accounts and regions under telemetry ingestion, expressed against the documented inventory so blind spots are visible cycle-on-cycle. |
| Cloud identity coverage ratio | Proportion of human and non-human identities (including service principals, managed identities, and federation paths) under behavioural baselining. |
| False positive rate | Proportion of alerts that turn out to be benign on triage; the leading indicator of detection tuning quality and operating cost. |
| Closed-loop verification rate | Proportion of validated incidents that produced a named remediation action that was completed and verified rather than left as an open record. |
Audit and Framework Crosswalk
CDR coverage records and incident records are direct evidence against several enterprise frameworks. The crosswalk below names the citations a GRC partner reads against the per-incident record and the per-account coverage map.
| Framework | Citation |
|---|---|
| ISO 27001:2022 | Annex A 8.16 (monitoring activities), A.5.23 (information security for use of cloud services), A.5.30 (ICT readiness for business continuity), A.8.20 (networks security). |
| ISO/IEC 27017 | Cloud-specific extensions to 27001 including shared-responsibility logging, cloud monitoring, and cross-tenant boundary controls. |
| SOC 2 | CC7.2 (system monitoring) and CC7.3 (security event evaluation); also CC6.1 (logical access). |
| PCI DSS v4.0 | Requirement 10 (logging and monitoring) and Requirement 11.5 (intrusion detection). |
| NIST SP 800-53 Rev 5 | SI-4 (system monitoring), AU-2 and AU-12 (audit logging), SC-7 (boundary protection), IR-4 (incident handling). |
| NIST CSF 2.0 | DE.AE (event analysis), DE.CM (continuous monitoring), RS.AN (response analysis), RS.CO (response communication). |
| DORA | Article 9 (protection and prevention), Article 17 (ICT-related incident management), Article 24 (testing of ICT tools). |
| NIS2 | Article 21 (cybersecurity risk management measures) and Article 23 (reporting obligations). |
How CDR Output Lands on the SecPortal Operating Record
CDR is an upstream detection platform. The platform layer below it is the consolidated security operating record that holds CDR-validated incidents alongside scanner findings, pentest findings, bug bounty submissions, and the wider vulnerability finding queue. SecPortal is one workspace that supports that consolidated record using verified product capabilities.
Findings management for validated incidents
Findings management with CVSS 3.1 holds each validated CDR incident as a finding with severity, named owner, target date, status across the lifecycle states, and the eight-field override chain for exceptions and acceptances. The CDR vendor produces the detection; the consolidated finding record holds the incident alongside other security findings so the prioritisation backlog and the audit- read record live on one source.
Bulk finding import from CDR output
Bulk finding import supports CSV intake from CDR platform exports so validated incidents land on the same workspace as scanner output, pentest findings, and bug bounty submissions. Column mapping covers the named identity, resource, region, MITRE ATT&CK technique, severity, and the response action taken on the CDR side.
Engagement management for cloud detection programmes
Engagement management binds CDR-validated incidents to the originating detection programme so per-account and per-cloud throughput is reproducible against the same record. A chartered cloud detection programme reads alongside pentest engagements, vulnerability assessment cycles, and code-scanning cycles.
AI reports for executive cadence
AI reports drafted by Claude summarise MTTD, MTTR, MTTC, account and region coverage, cloud identity coverage ratio, false positive rate, and closed-loop verification rate for the leadership cadence read. The narrative composes from the live engagement and per-finding record rather than from a static template.
Compliance tracking for framework crosswalk
Compliance tracking maps CDR coverage and incident records against ISO 27001 A.8.16, A.5.23, A.5.30, A.8.20, ISO/IEC 27017, SOC 2 CC7.2 and CC7.3, PCI DSS Requirement 10 and 11.5, NIST 800-53 SI-4, AU-2, AU-12, SC-7, NIST CSF 2.0 DE.AE and DE.CM, DORA Article 9, 17, 24, and NIS2 Article 21 and 23.
Activity log for evidence chain
Activity log with CSV export captures the named-actor chronology per finding so the cloud incident response record carries an evidence chain that holds at audit fieldwork. Retention scales by plan to 30, 90, or 365 days.
Document management for runbook and coverage map
Document management holds the versioned CDR runbook, the per-account coverage map, the response carve-out list, the escalation tree, the detection tuning backlog, and the framework crosswalk attestation. The named author and approver fields support the accountability chain at audit.
Team management with RBAC
Team management with role-based access supports the named-owner field on each finding. Roles cover owner, admin, member, viewer, and billing assignments so departed staff surface as inactive references rather than silent stale data.
Finding overrides for cloud detection exceptions
Finding overrides capture the eight-field decision chain for cloud detections accepted as known-benign (deployment automation patterns, scheduled cross-account replication, expected privileged sessions), with named approver, expiry, and review cadence.
Retesting workflows for fix verification
Retesting workflows pair the retest record to the original CDR- validated incident so the closed-loop verification metric is reproducible. A retest carries the same MITRE ATT&CK technique and the same affected identity or resource as the original incident.
Continuous monitoring for coverage drift
Continuous monitoring on the verified external surface complements the CDR control-plane and identity-plane coverage with periodic external scans on the cloud-hosted applications and APIs that the cloud account exposes. Scheduled re-runs catch regressions when a control-plane change opens an external surface.
SecPortal is not a CDR platform. SecPortal does not ingest CloudTrail or equivalent provider audit logs natively, does not run cloud behavioural analytics, does not execute cloud- provider response actions such as IAM user disable or key rotation, and does not ship packaged Jira, ServiceNow, Slack, Teams, PagerDuty, SIEM, SOAR, GRC, or CMDB connectors. SecPortal is the consolidated operating record that holds CDR-validated incidents alongside scanner findings, pentest findings, and bug bounty submissions so the cloud detection work does not live in a parallel backlog.
Procurement Criteria for CDR
CDR procurement separates a programme-grade platform from a CloudTrail dashboard subscription. Buyers should benchmark seven criteria against the cloud-account inventory the organisation actually operates.
- Per-cloud telemetry depth: which audit log surfaces the platform ingests on AWS, Azure, GCP, and any additional providers in scope; whether data events on critical buckets are included; whether identity-plane events and data-plane access logs are first-class sources.
- Per-cloud detection content: the named detection library per provider, the MITRE ATT&CK Cloud Matrix mapping, the rule-update cadence as cloud-provider feature releases create new surfaces, and the testing harness that validates detections survive cloud-provider API changes.
- Behavioural analytics depth: which dimensions are baselined (identity, role, region, service, workload class), the baseline learning window required, and the distribution-shift detection method.
- Response action set: which cloud-side actions the platform executes directly (IAM user disable, access key deactivation, role detach, session revocation, workload quarantine, key rotation), which require integration with the customer infrastructure, and which are detection-only.
- Multi-cloud and multi-account scale: how the platform handles the consolidated operating record across many accounts in many providers, what the per-account cost looks like, and what the cross-account correlation capabilities are.
- Evidence and reporting depth: the per-incident record structure, the executive cadence read, and the audit- grade output mapped against ISO 27001, ISO/IEC 27017, SOC 2, PCI DSS, NIST 800-53, NIST CSF 2.0, DORA, and NIS2.
- Operating model fit: whether the platform is bought as a discrete CDR, as a CNAPP module, or as part of an XDR umbrella; the staffing pattern the platform assumes (internal cloud SOC vs MDR pairing); and the runbook shape the platform produces by default.
Audience Lenses
CDR reads differently for different audience lenses. The same operating discipline appears as a procurement decision to one audience, a detection tuning backlog to another, and an audit evidence pack to a third.
Cloud security teams
The platform decision, the telemetry topology, the per-cloud detection content, the baseline learning discipline, and the response runbook. Cloud security owns the day-to-day operating record and the detection tuning backlog.
CISOs and security leaders
The procurement decision, the operating model choice (CDR vs CNAPP module vs XDR umbrella), the staffing pattern (internal cloud SOC vs MDR pairing), the programme scoreboard, and the audit-grade evidence pack that reads at framework audit and at cyber insurance renewal.
SOC and detection engineering
The detection content library, the MITRE ATT&CK Cloud Matrix coverage matrix, the false positive rate, the alert quality, the response action set, the runbook calibration, and the integration with the wider XDR or SIEM correlation layer above CDR.
AppSec and product security
The handoff from CDR-validated incidents to application-side remediation when the underlying cause is application configuration, leaked credentials in code, or insecure cloud SDK usage patterns the application team owns.
Vulnerability management
The intake path from CDR-validated incidents into the consolidated finding record so the cloud detection work does not live in a parallel backlog, the per-cloud prioritisation overlay on top of CVSS, and the closed-loop verification metric.
GRC and compliance
The cloud-specific framework crosswalk (ISO 27001, ISO/IEC 27017, SOC 2, PCI DSS, NIST 800-53, NIST CSF 2.0, DORA, NIS2), the per-incident record structure that reads as audit evidence, the retention model that supports audit fieldwork, and the cyber insurance renewal pack.
Scope and Limitations
This guide describes the operating shape of Cloud Detection and Response as it is consumed in mainstream enterprise cloud security programmes. The vendor landscape evolves rapidly: native integrations into specific cloud-provider APIs, packaged detection libraries, the depth of behavioural analytics, the precision-versus-recall properties of named platforms, the response action sets, the cross-account correlation capabilities, and the SLA structure that specific contracts ship with all shift between releases and renewals. Specific feature claims, supported cloud providers, supported response actions, telemetry topology requirements, and the latency and reliability characteristics of named platforms should be verified against current vendor documentation and against benchmark exercises on the organisation own cloud estate.
CDR is a cloud-side detection-and-response platform, not a remediation platform and not a prevention product. Programmes that adopt CDR without an underlying cloud telemetry strategy lose the visibility the platform depends on; programmes that adopt CDR with a calibrated runbook, named active response carve-outs, a baseline period that resolves the false-positive mix, and the post-incident remediation loop wired into the wider finding queue are the ones that see durable detection- and-response improvement over time.
Run CDR output on SecPortal
Stand up the operating record that holds CDR-validated incidents alongside scanner and pentest findings in under two minutes. Free plan available, no credit card required.