GuardDuty is on. Who reads the findings

You enabled Amazon GuardDuty months ago. It took about two clicks. The board deck said "threat detection enabled," the security questionnaire from your largest prospect got a clean checkmark, and everyone moved on. The dashboard is right there in the console, quietly running.

Now picture the actual Tuesday. A GuardDuty finding fires at 11:47 in the morning: an unusual API call from an Amazon Elastic Compute Cloud (EC2) instance, severity medium. Where does it go? Maybe an email alias nobody reads. Maybe a Slack channel that scrolls past it. Maybe an EventBridge rule somebody wrote during onboarding and forgot. The honest answer at a lot of growing companies is that it goes nowhere a human will see it in time. The detection worked. The finding is real. And it sits there, green console and all, because the part that turns a finding into a decision was never built.

That is the gap this piece is about. Enabling GuardDuty is step zero. The work that protects you starts the moment a finding appears, and that work is operational, not technical.

GuardDuty is genuinely good at its job. It analyzes foundational data sources (such as AWS CloudTrail management events, Amazon Virtual Private Cloud flow logs, and Domain Name System (DNS) query logs) to spot unexpected and potentially malicious activity in your account, according to the AWS GuardDuty documentation. Switch it on and it starts producing findings without you feeding it anything.

That is exactly why it lulls teams. The product does the part that looks like security: it watches, it scores, it generates findings. What it does not do is decide whether a given finding is an attacker, a misconfigured backup job, or a developer testing something at two a.m. It does not page the right person. It does not contain the instance. It does not write down what happened so your next auditor can read it. AWS is clear that GuardDuty produces findings for you to review and act on; the acting is yours.

So the question that matters is not "is GuardDuty on." It is "what happens between the finding firing and somebody deciding." If the answer is a shrug, the detector is a smoke alarm in an empty house.

Here is the operational reality once findings start flowing. A real account generates a steady stream of them, and most are not emergencies. The job is sorting the few that matter from the many that do not, fast enough to act, every single day. That breaks into a handful of jobs that need an owner:

• Routing. Every finding lands somewhere a human is watching, with a severity that decides how loud the alert is. Medium findings should not page anyone at three a.m.; a confirmed credential compromise should.
• Triage. Someone looks at the finding in context and answers one question: is this real, and does it need action now. That judgment is the whole game, and it is a person's judgment, not a rule.
• Response. When the answer is yes, somebody isolates the instance, rotates the key, or revokes the session, and does it from a known runbook so the steps are the same at 11:47 a.m. and at midnight.
• Record. What fired, what we decided, what we did, and when. This is the part everyone skips and the part your SOC 2 auditor and your next enterprise buyer will ask about by name.

None of that is a product you can buy and switch on. It is a standing operation. The tooling to run it is already in your account: GuardDuty for detection, EventBridge for routing, AWS Security Hub to aggregate, runbooks for response. The missing piece is the people and the habit to run it on a schedule, not on luck.

Most growing companies on AWS are not under-tooled. They are under-operated. You have probably already paid for the detection. What you do not have is a named person whose job is to read the findings every day, decide, act, and log it, and to keep doing that on the quiet Tuesdays when nothing seems to be happening.

That is the same reason a lot of mid-market breaches do not look like movie hacks. The signal was there. GuardDuty, or the equivalent, fired. The finding scrolled past in a channel nobody owned, or landed in an inbox nobody read, and the window to act closed before anyone looked. The failure was operational, not a missing feature.

A detector with no one reading it is not security. It is documentation of an incident you will discover later.

This is why we treat security as an operating problem first. We run the triage loop inside your account: findings route to people who read them, real ones get worked from a runbook, and every decision lands in a record your auditor can pull without a meeting. You keep the AWS-native stack you already chose. We supply the part AWS was never going to supply, which is the human on the other end of the finding.

Go back to that 11:47 finding. In a healthy operation it routes to a person within minutes, gets triaged against what your environment normally does, and either closes as noise with a note or escalates to a response that follows a written runbook. By the time it would have reached your inbox as a surprise, it is already handled and logged. The console stays green because something green-keeping happened, not because nobody was looking.

GuardDuty being on tells you the smoke alarm has batteries. It does not tell you anyone is home. So the question worth carrying out of this is simple, and it is the one a prospect's security team or your own board will eventually ask: when GuardDuty fires on a Tuesday afternoon, who reads it, and what happens next?