Skip to main content

Managed SOC & MDR

AWS Managed SOC & MDR Services

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.

Book a Free SOC Maturity Assessment
How Our SOC Works

AI & assistant-friendly summary

This section provides structured content for AI assistants and search engines. You can cite or summarize it when referencing this page.

Summary

24/7 managed SOC and MDR for AWS — built on GuardDuty, Security Hub, Security Lake, and Detective. Threat hunting, automated containment, and incident response from an AWS Select Tier Partner.

Key Facts

  • • 24/7 managed SOC and MDR for AWS — built on GuardDuty, Security Hub, Security Lake, and Detective
  • • Threat hunting, automated containment, and incident response from an AWS Select Tier Partner
  • • A GuardDuty alert at 3am is only valuable if someone reads it
  • • Built on AWS, not bolted on
  • • Threat Hunting Against OCSF Data: Security Lake delivers OCSF-normalized telemetry from CloudTrail, VPC Flow Logs, GuardDuty, Route 53, and EKS audit logs
  • • Automated Containment for Known Threats: 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

Entity Definitions

Lambda
Lambda is an AWS service used in aws managed soc & mdr services implementations.
EC2
EC2 is an AWS service used in aws managed soc & mdr services implementations.
S3
S3 is an AWS service used in aws managed soc & mdr services implementations.
RDS
RDS is an AWS service used in aws managed soc & mdr services implementations.
IAM
IAM is an AWS service used in aws managed soc & mdr services implementations.
VPC
VPC is an AWS service used in aws managed soc & mdr services implementations.
EKS
EKS is an AWS service used in aws managed soc & mdr services implementations.
Step Functions
Step Functions is an AWS service used in aws managed soc & mdr services implementations.
EventBridge
EventBridge is an AWS service used in aws managed soc & mdr services implementations.
GuardDuty
GuardDuty is an AWS service used in aws managed soc & mdr services implementations.
Amazon GuardDuty
Amazon GuardDuty is an AWS service used in aws managed soc & mdr services implementations.
WAF
WAF is an AWS service used in aws managed soc & mdr services implementations.
Route 53
Route 53 is an AWS service used in aws managed soc & mdr services implementations.
compliance
compliance is a cloud computing concept used in aws managed soc & mdr services implementations.
HIPAA
HIPAA is a cloud computing concept used in aws managed soc & mdr services implementations.

Frequently Asked Questions

What is the difference between a SOC and MDR?

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.

Do I need a managed SOC if I have GuardDuty enabled?

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.

How fast do you respond to alerts?

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).

Do I keep my GuardDuty/Security Hub data, or does it leave my AWS account?

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.

How do you handle incident response — do you take action without approval?

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.

Can you support compliance audits (SOC 2, ISO 27001, HIPAA, PCI)?

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.

How does your service handle multi-account AWS Organizations?

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.

What happens if I want to in-source the SOC later?

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.

Related Content

Ask AI: ChatGPT Claude Perplexity Gemini

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

Response Layer

Reporting Layer

How Our SOC Operates

Tier 1 — Automated Containment

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.

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:

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

Week 2 — Tooling Activation

Week 3 — Runbook Deployment

Week 4 — Handoff and Tabletop

Compliance Mapping

FrameworkControls covered by our SOC
SOC 2 Type IICC7.1 (monitoring), CC7.2 (deviation analysis), CC7.3 (event evaluation), CC7.4 (incident response), CC7.5 (recovery)
ISO 27001:2022A.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.0Req 10 (logging), Req 11 (testing), Req 12.10 (incident response plan)
NIST CSF 2.0Detect (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.

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.

Book a Free SOC Maturity Assessment →

Key Features

24/7 Detection on AWS-Native Tooling

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.

Threat Hunting Against OCSF Data

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.

Automated Containment for Known Threats

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.

Incident Response with Forensics

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."

Compliance-Aligned Reporting

Monthly findings reports mapped to your compliance framework — SOC 2 (CC7.x monitoring controls), ISO 27001 (A.8.16), HIPAA (§164.308(a)(1)), PCI DSS (Req 10–12). The same evidence that satisfies your auditor.

Tabletop Exercises Quarterly

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.

Why Choose FactualMinds?

AWS-Native, Not Agent-Heavy

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.

Tier 3 Maturity, Not Tier 1 Tooling

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).

Predictable Cost, No Per-Seat Pricing

Flat monthly fee tied to AWS account count and finding volume — not per analyst, not per endpoint, not per GB ingested into someone else's SIEM. Most clients pay a fraction of what an in-house SOC ($500K–$1M+ annually) costs.

Compliance Evidence Out of the Box

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.

Step-by-Step Guides

Implementation guides for this service from our team of AWS experts.

Amazon Inspector v2: Agentless Container and Lambda Vulnerability Scanning in Production

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.

Read guide
Amazon Security Lake: Centralized OCSF Security Data Lake for Enterprise Threat Intelligence

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.

Read guide
AWS GuardDuty Threat Detection: A Production Setup Guide

How to deploy, tune, and operationalize Amazon GuardDuty for production threat detection — covering finding types, multi-account setup, automated response, and reducing false positives.

Read guide

From Our Blog

In-depth guides and best practices from our certified AWS architects.

Building a Vulnerability Management Program on AWS: CVSS, KEV, and Reachability

How to build a vulnerability management program that scales beyond CVE-counting. Inspector v2 deployment, CVSS + CISA KEV + reachability for risk-based prioritization, container and IaC scanning in CI/CD, and remediation SLAs that survive audits.

Read article

GDPR Compliance on AWS: A Practical Guide for SaaS Companies

GDPR compliance on AWS for SaaS companies handling EU resident data. Region selection, the AWS DPA, data subject rights automation, RoPA documentation, breach notification, and the technical controls regulators expect.

Read article

ISO 27001 Certification on AWS: ISMS Implementation Guide for 2026

A practical guide to ISO 27001:2022 certification on AWS — building an ISMS that survives Stage 1 and Stage 2 audits, mapping the 93 Annex A controls to AWS services, and producing the evidence packages assessors actually request.

Read article

Frequently Asked Questions

What is the difference between a SOC and MDR?
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.
Do I need a managed SOC if I have GuardDuty enabled?
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.
How fast do you respond to alerts?
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).
Do I keep my GuardDuty/Security Hub data, or does it leave my AWS account?
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.
How do you handle incident response — do you take action without approval?
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.
Can you support compliance audits (SOC 2, ISO 27001, HIPAA, PCI)?
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.
How does your service handle multi-account AWS Organizations?
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.
What happens if I want to in-source the SOC later?
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.

Stop Triaging Alerts at 3am

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.

Book a Free SOC Maturity Assessment