24/7 AWS SOC, fixed monthly fee
A GuardDuty alert at 3am is only valuable if someone reads it. Our managed SOC operates AWS-native detection 24/7 — triaging GuardDuty, Security Hub, and Detective findings; running automated containment for known threats; and escalating to a human analyst when behavior crosses your runbook threshold. Built on AWS, not bolted on.
This section provides structured content for AI assistants and search engines. You can cite or summarize it when referencing this page.
24/7 managed SOC and MDR for AWS — GuardDuty, Security Hub, Security Lake. Threat hunting, automated containment, incident response from an AWS Select Tier Partner.
SOC (Security Operations Center) is an organizational function — analysts watching dashboards, triaging alerts, and managing investigations. MDR (Managed Detection and Response) is a packaged service that delivers SOC capabilities, typically with vendor-defined tooling, runbooks, and analyst staffing. Our service combines both: we deliver MDR (the packaged capability) operating as your SOC (the function). The output is the same — 24/7 trained analysts triaging findings, running containment, and escalating incidents — without the $500K–$1M+ cost of building it in-house.
GuardDuty generates findings; it does not respond to them. Most organizations that "have GuardDuty" actually have an inbox where findings accumulate unread. A managed SOC is the operational layer that turns findings into action — triaging severity, applying threat intelligence context, executing containment runbooks, and escalating to humans when automation is not enough. If your team checks GuardDuty findings less than daily and has no documented response runbook, you do not have effective threat detection — you have logs.
Our triage SLA is 15 minutes for high-severity GuardDuty/Security Hub findings during business hours and 30 minutes after-hours. For known threat patterns with automated containment runbooks, response is real-time (the containment runs before a human is paged). For incidents requiring investigation, our analyst is engaged within 1 hour of declaration and follows your documented IR runbook (or ours, if you do not have one).
Your data stays in your AWS organization. We operate as a delegated administrator within your AWS Organizations setup — using cross-account IAM roles with explicit, scoped permissions for reading findings, querying Security Lake, and executing pre-approved containment actions. We do not ship logs to a third-party SIEM. We do not aggregate your data with other clients. Your account, your data, our analysts.
It depends on the runbook tier. Tier 1 (low-severity, well-understood patterns): automated containment runs without approval — e.g., a public S3 bucket on a non-whitelisted resource is auto-remediated. Tier 2 (high-severity, known patterns): we execute the runbook and notify in real-time — e.g., compromised IAM credentials get rotated, owner is paged. Tier 3 (incidents requiring investigation): we engage the on-call from your team, lead the response, and require explicit approval for destructive actions like resource termination. The runbook tier for each finding type is documented and approved by you during onboarding.
Yes. Our monthly SOC reports are formatted as audit evidence for the most common frameworks. SOC 2 Trust Service Criteria CC7.1–CC7.5 (monitoring), ISO 27001 Annex A.8.15–A.8.16 (logging and monitoring), HIPAA §164.308(a)(1) (security management process), and PCI DSS Requirements 10–12 (logging, testing, incident response) are covered by our standard reporting. We work directly with your auditor to provide evidence walkthroughs when requested.
We onboard via AWS Organizations delegated administration — taking delegated administrator status for GuardDuty, Security Hub, Macie, Inspector v2, and IAM Access Analyzer. This gives our SOC visibility across every account in your Organization without requiring per-account IAM roles or agent installation. We support both standard AWS Organizations and Control Tower environments. For environments using AWS GovCloud (US), we provide a separate SOC capability with US-person analysts only.
AWS expanded GuardDuty Extended Threat Detection in 2026 with new attack-sequence findings for Amazon EC2 instances and Amazon ECS tasks, building on earlier coverage for IAM credential misuse, suspicious S3 activity, and EKS cluster compromise. Extended Threat Detection correlates runtime activity, malware detections, VPC Flow Logs, DNS queries, and CloudTrail events to identify multi-stage attacks, and it integrates exposure and vulnerability context from AWS Security Hub for better prioritization. The capability is automatically enabled for new and existing GuardDuty customers in all supported commercial Regions at no additional cost. Our SOC playbooks consume these correlated sequence findings as Tier 2 incidents — automation gathers context, then a human owns the response.
Yes. The redesigned AWS Security Hub (GA at re:Inforce 2025) is the primary dashboard our analysts work from. It calculates exposure in near real-time by correlating GuardDuty threats, Inspector vulnerabilities, and Security Hub CSPM misconfigurations into a single prioritized view, includes a Security coverage widget that surfaces accounts and Regions missing GuardDuty / Inspector / Macie / Security Hub CSPM enablement, and provides up to one year of trend history across findings and resources. We also ingest Security Hub CSPM findings into Amazon CloudWatch (supported since March 2026) for cross-team observability alongside operational telemetry.
Our service is designed for in-sourcing graduation. We document every runbook, finding type, and automation playbook in your environment — owned by you, not us. When you are ready to bring SOC operations in-house, we transfer the runbooks, train your team on the tooling we built, and operate in parallel during transition. No proprietary platform lock-in. Most clients keep us as Tier 3 escalation even after building internal Tier 1/2 capability.
## What is a Managed SOC and MDR? A Managed Security Operations Center (SOC) is an outsourced 24/7 service that monitors your AWS environment for threats, triages every finding, and responds to incidents. Managed Detection and Response (MDR) extends a SOC with active threat hunting and automated containment — analysts use AWS-native services (GuardDuty, Security Hub, Detective, Security Lake) to detect, investigate, and stop attacks before they escalate. ## Why a Managed SOC for AWS The dominant security failure mode in AWS environments is not exotic exploits — it is **alerts nobody acts on**. GuardDuty fires; the finding lands in an inbox; nobody triages; the issue compounds; the breach happens later. Industry research is unambiguous on this: misconfiguration and ignored alerts cause the majority of cloud incidents. A managed SOC closes that gap. We operate AWS-native detection 24/7, triage every finding above a defined severity, run automated containment for known threats, and engage human analysts when behavior breaks the runbook. The output is not "better alerts" — the output is **alerts that get answered**, evidence that gets logged, and incidents that get contained while they are still small. ## What Our Managed SOC Covers ### Detection Layer - **Amazon GuardDuty** — continuous threat detection across compute, S3, EKS, RDS, and Lambda - **AWS Security Hub** — aggregated findings from GuardDuty, Inspector v2, Macie, and Config - **Amazon Inspector v2** — agentless vulnerability scanning for EC2, ECR, and Lambda - **Amazon Macie** — sensitive data discovery and unusual access pattern detection in S3 - **Amazon Detective** — behavior graphs for investigation - **Amazon Security Lake** — OCSF-normalized telemetry for cross-source threat hunting - **AWS Network Firewall + WAF** — Layer 7 attack detection and blocking ### Response Layer - **EventBridge + Lambda** — automated containment runbooks - **Step Functions** — multi-step IR orchestration - **Systems Manager Automation** — patch and remediation playbooks - **CloudTrail Lake** — long-retention forensic queries - **Cross-account IAM roles** — scoped permissions for our SOC analysts to operate inside your accounts ### Reporting Layer - Monthly SOC report (compliance-aligned) - Weekly threat hunt summary - Real-time dashboards for your security team and leadership - Quarterly tabletop exercise reports - Annual SOC maturity assessment ## How Our SOC Operates ### Tier 1 — Automated Containment For well-understood threat patterns, response is real-time and automatic: - Public S3 bucket detected → auto-remediated (Block Public Access reapplied) - IAM credentials in code → owner notified, key rotation triggered - Compromised EC2 reaching known C2 domains → quarantine security group attached - Root account login → immediate alert + MFA forced re-auth - Inspector v2 critical CVE on internet-facing resource → patching workflow opened These runbooks are pre-approved during onboarding and execute without human pause. Notification still happens — but the threat is already contained. ### Tier 2 — Analyst Triage For findings that require context — is this a real threat or a false positive? — our analysts engage within the SLA window. Triage involves: - Reviewing the finding in Security Hub and Detective - Querying CloudTrail Lake for related activity - Cross-referencing Security Lake for behavioral patterns - Determining whether automated containment runbooks apply - Engaging your team if incident declaration is warranted ### Tier 3 — Incident Response When a finding becomes an incident, our SOC leads the response: 1. **Declaration** — formal incident ticket opened, severity assigned, stakeholders notified 2. **Containment** — forensic snapshots captured before remediation 3. **Investigation** — Detective and Security Lake analysis to map blast radius 4. **Eradication** — credentials rotated, malicious resources terminated, vulnerabilities patched 5. **Recovery** — verified restoration of affected services 6. **Post-incident review** — written root-cause analysis, runbook updates, lessons-learned distribution For organizations with regulatory obligations (HIPAA, GDPR, PCI), our IR process includes regulator notification timeline tracking — the 72-hour GDPR clock starts when GuardDuty alerted, not when you decided. ## Onboarding Process ### Week 1 — Environment Discovery - AWS Organizations structure mapped - Existing GuardDuty / Security Hub / Inspector / Macie state assessed - Account criticality classification with your team - Compliance scope confirmed (which frameworks, which controls) ### Week 2 — Tooling Activation - GuardDuty, Security Hub, Inspector v2, and Macie enabled organization-wide via delegated admin - Security Lake stood up; OCSF data sources configured - Cross-account IAM roles for our SOC, scoped via permission boundaries - EventBridge rules and Lambda automation deployed - Initial runbook approval with your team ### Week 3 — Runbook Deployment - Tier 1 automated containment runbooks deployed - Tier 2 analyst triage workflows configured - Tier 3 incident response playbook approved - Notification channels (Slack, PagerDuty, email) wired ### Week 4 — Handoff and Tabletop - Initial threat hunt completed - Tabletop exercise run against your specific architecture - Monthly reporting cadence agreed - 24/7 operations begin ## Compliance Mapping | Framework | Controls covered by our SOC | | -------------- | --------------------------------------------------------------------------------------------------------------------- | | SOC 2 Type II | CC7.1 (monitoring), CC7.2 (deviation analysis), CC7.3 (event evaluation), CC7.4 (incident response), CC7.5 (recovery) | | ISO 27001:2022 | A.5.24–A.5.30 (incident management, BCM), A.8.15 (logging), A.8.16 (monitoring activities) | | HIPAA | §164.308(a)(1) (security management), §164.308(a)(6) (security incident procedures), §164.312(b) (audit controls) | | PCI DSS 4.0 | Req 10 (logging), Req 11 (testing), Req 12.10 (incident response plan) | | NIST CSF 2.0 | Detect (DE.CM-01 to DE.AE-08), Respond (RS.MA-01 to RS.MI-02), Recover (RC.RP-01 to RC.IM-02) | For organizations targeting multiple frameworks, our reporting consolidates evidence across all applicable controls — reducing audit prep time significantly. ## Related Services and Resources - [AWS Cloud Security Consulting](/services/aws-cloud-security/) — for organizations needing a security assessment before standing up the SOC - [Cloud Compliance Services](/services/cloud-compliance-services/) — for the full compliance program (gap assessment, control implementation, audit support) - [AWS Penetration Testing](/services/aws-penetration-testing/) — for offensive validation of defensive controls - [AWS GuardDuty Production Setup](/aws-guardduty-threat-detection-production-guide/) — our blog post on GuardDuty operational deployment - [Automating AWS Security Remediation](/from-reactive-to-proactive-automating-aws-security-remediation/) — the automation patterns we deploy on day one ## Get Started If your team is exhausted from triaging GuardDuty alerts, your last security incident took 6 hours to contain because nobody noticed for 4, or your compliance auditor is asking for "evidence of continuous monitoring" — let us run the SOC for you. [Get a 24/7 SOC Coverage Plan →](/contact-us/)
A Managed Security Operations Center (SOC) is an outsourced 24/7 service that monitors your AWS environment for threats, triages every finding, and responds to incidents. Managed Detection and Response (MDR) extends a SOC with active threat hunting and automated containment — analysts use AWS-native services (GuardDuty, Security Hub, Detective, Security Lake) to detect, investigate, and stop attacks before they escalate.
The dominant security failure mode in AWS environments is not exotic exploits — it is alerts nobody acts on. GuardDuty fires; the finding lands in an inbox; nobody triages; the issue compounds; the breach happens later. Industry research is unambiguous on this: misconfiguration and ignored alerts cause the majority of cloud incidents.
A managed SOC closes that gap. We operate AWS-native detection 24/7, triage every finding above a defined severity, run automated containment for known threats, and engage human analysts when behavior breaks the runbook. The output is not “better alerts” — the output is alerts that get answered, evidence that gets logged, and incidents that get contained while they are still small.
For well-understood threat patterns, response is real-time and automatic:
These runbooks are pre-approved during onboarding and execute without human pause. Notification still happens — but the threat is already contained.
For findings that require context — is this a real threat or a false positive? — our analysts engage within the SLA window. Triage involves:
When a finding becomes an incident, our SOC leads the response:
For organizations with regulatory obligations (HIPAA, GDPR, PCI), our IR process includes regulator notification timeline tracking — the 72-hour GDPR clock starts when GuardDuty alerted, not when you decided.
| Framework | Controls covered by our SOC |
|---|---|
| SOC 2 Type II | CC7.1 (monitoring), CC7.2 (deviation analysis), CC7.3 (event evaluation), CC7.4 (incident response), CC7.5 (recovery) |
| ISO 27001:2022 | A.5.24–A.5.30 (incident management, BCM), A.8.15 (logging), A.8.16 (monitoring activities) |
| HIPAA | §164.308(a)(1) (security management), §164.308(a)(6) (security incident procedures), §164.312(b) (audit controls) |
| PCI DSS 4.0 | Req 10 (logging), Req 11 (testing), Req 12.10 (incident response plan) |
| NIST CSF 2.0 | Detect (DE.CM-01 to DE.AE-08), Respond (RS.MA-01 to RS.MI-02), Recover (RC.RP-01 to RC.IM-02) |
For organizations targeting multiple frameworks, our reporting consolidates evidence across all applicable controls — reducing audit prep time significantly.
If your team is exhausted from triaging GuardDuty alerts, your last security incident took 6 hours to contain because nobody noticed for 4, or your compliance auditor is asking for “evidence of continuous monitoring” — let us run the SOC for you.
GuardDuty (now including Extended Threat Detection AI/ML attack-sequence findings for EC2 and ECS), Security Hub with real-time exposure dashboards and 1-year trend history, Inspector v2, Macie, Detective, and Security Lake — operating inside your AWS organization, with our analysts on the other end of every notable finding. No agent install, no third-party SIEM tax. Triage SLA: 15 minutes business hours, 30 minutes after-hours.
Security Lake delivers OCSF-normalized telemetry from CloudTrail, VPC Flow Logs, GuardDuty, Route 53, and EKS audit logs. Our analysts hunt against this data weekly — looking for behavioral patterns that single-source detection misses.
Public S3 bucket detected → auto-remediated. Compromised IAM credentials → session policy attached, keys rotated, owner notified. Suspicious EC2 instance → quarantined to an isolated security group. The human only escalates the cases automation cannot.
When containment escalates to incident, we execute the runbooks in our incident response guide — forensic snapshot capture, CloudTrail Lake queries, Detective behavior analysis, and root-cause documentation. Compliance drift (Config control failures) routes to a hardening backlog, not the pager.
Monthly findings reports mapped to the controls your auditor asks for — SOC 2 CC7.1–CC7.5, ISO 27001 A.8.15–A.8.16, HIPAA §164.308(a)(1), PCI DSS Req 10–12. The CSV your assessor needs, generated automatically every month.
Documented runbooks survive contact with reality only if you test them. We run quarterly tabletop exercises against your specific architecture — credential compromise, data exfiltration, ransomware on EKS — and update runbooks based on what broke.
Most MDR providers want to install endpoint agents and forward logs to their proprietary platform. Our SOC operates inside your AWS environment using AWS-native services. Your data does not leave your account.
Buying GuardDuty does not make you mature. Operating it does. We bring the runbooks, escalation paths, automation playbooks, and trained analysts that move you from Tier 1 (alerts ignored) to Tier 3 (alerts triaged, contained, and learned from).
Flat monthly fee tied to AWS account count and finding volume — no per-analyst, per-endpoint, or per-GB surprises. Most clients run a 24/7 SOC for 15–25% of the cost of building an in-house team ($500K–$1M+ annually).
Monthly SOC reports double as audit evidence. Our analysts already document with the control language your assessor expects. No translation layer between detection and audit prep.
Implementation guides for this service from our team of AWS experts.
How to deploy, tune, and operationalize Amazon GuardDuty for production threat detection — covering finding types, multi-account setup, automated response, and reducing false positives.
Inspector v2 continuously scans EC2, ECR container images, and Lambda functions without agents. Production guide to CI/CD integration, finding management, risk scoring, and multi-account deployment.
Amazon Security Lake normalizes security logs to OCSF format in a centralized S3 data lake. Here's how to build a cost-effective security data platform without a $500K SIEM contract.
Two 2025 shifts rewrite the IR playbook: GuardDuty Extended Threat Detection now emits a single critical attack-sequence finding instead of a pile of high findings, and AWS Security Incident Response moved to metered pricing (free first 10,000 findings/month, then $0.000676 each) on November 21, 2025. The lesson is to page humans on the <1% of correlated criticals, isolate instead of terminate, and let auto-triage absorb the rest. Here are the runbooks.
Manual security triage cannot keep up with cloud-scale threats. Here is how to wire GuardDuty Extended Threat Detection, Security Hub, EventBridge, and Lambda into a self-healing AWS security architecture.
Third-party tools we frequently wire into AWS as part of this engagement — production-tested integration guides for each.
Datadog on AWS in 2026: unified observability for CloudWatch, EKS, Lambda, Bedrock LLM workloads, and security posture across multi-cloud estates.
Okta + AWS in 2026: Workforce Identity SSO into IAM Identity Center, Identity Threat Protection, ISPM, Device Access, passkeys, and Verified Access.
Architecture patterns, decision trees, and glossary terms that map to this engagement.
AWS audit logging service that records every API call and account activity across your AWS infrastructure for security, compliance, and operational investigation.
AWS monitoring and observability service for collecting metrics, logs, traces, and setting alarms across AWS infrastructure and applications.
In-depth guides and best practices from our certified AWS architects.
Security Hub detects control failures. It is not the compliance pipeline — and treating it as one is why teams still scramble for evidence at audit time. The four jobs are distinct: AWS Config detects drift, conformance packs deploy rules org-wide as immutable bundles, SSM Automation remediates the safe class, and evidence accrues via conformance-pack exports plus Security Hub control status (Audit Manager only if you onboarded before it closed to new customers on 30 April 2026). Here is the tool-per-job matrix, a conformance pack with auto-remediation, and the auto-remediation gotcha to design around.
Read articleTwo 2025 shifts rewrite the IR playbook: GuardDuty Extended Threat Detection now emits a single critical attack-sequence finding instead of a pile of high findings, and AWS Security Incident Response moved to metered pricing (free first 10,000 findings/month, then $0.000676 each) on November 21, 2025. The lesson is to page humans on the <1% of correlated criticals, isolate instead of terminate, and let auto-triage absorb the rest. Here are the runbooks.
Read articleMost KMS guides stop at "enable encryption." The architecture decision that actually bites is the key boundary: split one CMK into 3,200 per-tenant keys and you pay ~$3,200/mo in key storage alone while still sharing a single 10,000 req/s symmetric quota. Here is the decision matrix, the throttle math, and the encryption-context pattern that gives per-tenant isolation without per-tenant keys.
Read articleIn-depth comparisons to help you choose the right approach before engaging.
24/7 managed detection and response for your AWS environment — built on GuardDuty, Security Hub, and Security Lake. AWS-native, compliance-aligned, and operated by analysts who already know your runbook.
