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.
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, Security Hub, Inspector v2, Macie, Detective, and Security Lake — operating in your AWS organization, with our analysts on the other end of every notable finding. No agent install, no third-party SIEM tax, no log shipping outside your account. Triage SLA: 15 minutes during 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 lead the response: forensic snapshot capture, CloudTrail Lake queries, Detective behavior analysis, and root-cause documentation. You get the IR runbook executed, not a Slack message saying "you have a problem."
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.
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.
How to deploy, tune, and operationalize Amazon GuardDuty for production threat detection — covering finding types, multi-account setup, automated response, and reducing false positives.
In-depth guides and best practices from our certified AWS architects.
GitHub Actions OIDC role sessions are short-lived by design—teams still paste static access keys into workflow logs until scanners or audits catch the diff; supply-chain writeups keep repeating the pattern into 2026.
Read articleBedrock Automated Reasoning checks ground LLM outputs against formal logic policies you encode and mathematically validate that the response is consistent with the policy. This guide covers when to use Automated Reasoning vs contextual grounding, how to author the policy in production, the integration with Bedrock Guardrails, and the regulated use cases (HR, insurance, eligibility, regulatory determinations) where the difference matters.
Read articleCloudTrail Event History on the default plan isn't your audit trail — it's a 90-day story you tell auditors. A production CloudTrail setup with multi-region trails, KMS encryption, log file integrity validation, and CloudTrail Lake as the queryable layer for incident response and compliance evidence.
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.
We use cookies and similar technologies to analyze site traffic, personalize content, and provide social media features. By clicking "Accept," you consent to our use of cookies. You can adjust your preferences at any time.
