Start with the required outcome and the current service names
Choose the next capability from a specific question, the accounts and Regions in scope, the evidence you need and the people who will act. Team size alone does not establish that GuardDuty should precede posture checks. Detection, posture and response can have parallel requirements.
Distinguish the services · Check billing scope · Compare the questions · Copy a bounded verification plan
Define the scope, authority and operating owner
Record the account structure, workloads, data sensitivity, service administrators and permitted changes. This guide does not authorize changes in an AWS account. Before a rollout or test, identify the person who approves it, reviews costs and owns downstream responses.
Write the required outcome in concrete terms: investigate suspicious activity, evaluate a particular configuration condition, correlate supported findings or verify delivery to an existing response process. A service being enabled is not the same as the outcome being verified.
GuardDuty: ask which activity and protection capability matter
Amazon GuardDuty is a threat-detection service that analyzes supported AWS data sources. Available protection capabilities and their coverage differ; review the exact account, Region, resource types and enabled settings rather than treating the service name as complete coverage.
The current guide describes defaults that vary between first-time enablement and plans introduced for existing customers. Record what is actually enabled and what the relevant capability requires. A quiet findings list does not establish that activity was collected, analyzed or safe.
If threat detection is the immediate gap, investigate the relevant GuardDuty capabilities and the response path. That is a task-specific reason to prioritize work, not a universal rule for every small team.
Security Hub CSPM: ask which control and population need checking
Security Hub CSPM evaluates supported configuration controls and consolidates supported security findings. Most control checks require appropriate AWS Config recording. Review the chosen controls, covered resources and prerequisites; an enabled standard does not establish that all checks completed or all resources were assessed.
A posture gap can justify CSPM work immediately, alongside detection work or before a separate expansion. Record the actual condition and owner. A passed control, score or collection of findings is not by itself a complete compliance assessment.
Security Hub, Security Hub CSPM and GuardDuty are distinct names
The current AWS service distinction describes Security Hub CSPM as posture evaluation and Security Hub as a unified experience for prioritizing and responding to security issues. Security Hub can correlate CSPM findings with other sources to generate exposures. Do not read an older use of “Security Hub” as automatically describing the current unified plan.
For a proposal, name the exact service, plan and capabilities. Separate the originating detection or control finding from the system that receives, correlates or routes it. These roles can complement each other; neither a dashboard nor a service label establishes the whole response workflow.
Review what the team already operates
Inventory existing detection, posture, logging, investigation and response arrangements before proposing another service. Include managed providers and organization-level settings. A small team may already have centrally managed coverage; a larger team may still have an unowned gap.
Record administrators, member accounts, intended Regions, covered resource types and known exclusions. Compare the desired state with evidence from the actual environment. Do not infer a need for a new service solely from the number of engineers or AWS accounts.
Compare the actual billing model and included capabilities
The current Security Hub pricing page distinguishes unified plans from individual service pricing. It states that services such as GuardDuty and Security Hub CSPM remain available separately when Security Hub is not enabled. Capabilities outside a selected plan can retain separate charges. Do not add two nominal prices without checking what is already included.
The Security Hub trial does not cover every add-on or plan. Individual-service trial eligibility and related charges can differ. Confirm current terms and use the provider’s estimate for the actual account and Region scope; this article gives no live quote.
Record currency, pricing date, billable resource or usage dimensions, plan inclusions, exclusions, trial end, related services and growth assumptions. Keep the estimate separate from observed charges and the internal work needed to triage, investigate and maintain the workflow. Mark missing values unknown rather than zero.
Define who interprets and acts on a finding
Record the receiving queue, named owner or rotation, escalation conditions and authority to make changes. A notification reaching a shared channel does not establish acknowledgment, investigation or remediation.
Keep severity distinct from operational priority. Describe the affected asset, identity, environment and evidence rather than applying a blanket rule that every finding from one service outranks every finding from another. If a finding is suppressed or closed, keep the reason, evidence, owner and review condition.
Automated responses need their own scope, permissions, review and recovery plan. Do not attach disruptive actions to unreviewed sample events or placeholder resource values.
Use phases with evidence-based exit conditions
- Document the need: define the question, population, existing coverage, cost assumptions and accountable owner.
- Review configuration: check the selected capability, prerequisites and intended boundary against current documentation.
- Verify the relevant behavior: distinguish configuration review, sample delivery, a completed posture check and a separately authorized detection exercise.
- Review the result: record what was established, what failed or remained unknown, and what must be checked before expanding.
The phases have no mandatory thirty-day schedule or service order. Choose review dates from the task and operational constraints. Do not report an incomplete phase as passed merely because its planned date arrived.
Trace the handoff from source finding to response
Document each required link: source service, account and Region, receiving service or event route, relevant filter, notification or ticket, acknowledgment and handling decision. Check the current GuardDuty–CSPM integration documentation for the intended handoff.
Test the actual required path. A finding visible in its source console does not establish arrival in another account, Region, dashboard or queue. Duplicated deliveries do not establish two independent detections. Preserve identifiers and timestamps so a reviewer can trace what happened without guessing.
Compare the question and the evidence needed
This is a question map, not a ranking or an enablement instruction. Scroll horizontally for all columns; focus the region to use arrow keys.
| Question | Capability to investigate | Evidence to record |
|---|---|---|
| Is suspicious activity detected for this workload? | Relevant GuardDuty protection capability | Coverage, prerequisites, authorized test boundary and observed result |
| Does a supported configuration control fail? | Relevant CSPM control | Actual check result, resource population, recorder state and exceptions |
| How are supported risks correlated and prioritized? | Current Security Hub plan and inputs | Sources present, expected correlation and limits of the resulting view |
| Does the owner receive and acknowledge a finding? | Configured delivery and response path | Source identifier, destination, timestamps, acknowledgment and failure points |
| What will this change cost? | Actual plan and related-service estimate | Included capabilities, billable units, trial limits, exclusions and observed usage |
Avoid conclusions the check did not establish
- Do not call a sample notification proof that an attack was detected.
- Do not call an enabled service proof of complete account, Region or resource coverage.
- Do not call a posture score an audit opinion or a guarantee of security.
- Do not count included capabilities again as independent charges without reviewing the plan.
- Do not infer that an automatic response was safe because its rule matched.
- Do not use team size as a substitute for the required outcome and operating evidence.
Questions about the comparison
Must every small team enable GuardDuty first?
No. Identify the immediate detection, posture and response gaps, current coverage, cost and owners. A documented need can justify parallel work or a different sequence.
Does Security Hub CSPM mean the current Security Hub plan?
No. Name the exact service and plan. Use the current service distinction and pricing documents rather than assuming older descriptions are equivalent.
Does generating a sample prove detection coverage?
No. It can support a delivery-path exercise. A completed detection or posture verification is a different claim with different evidence.
Does the trial mean every related service is free?
No. Check included capabilities, separate-service eligibility and related charges for the actual scope.
Copy a bounded verification plan
Choose the task and obtain the appropriate approval before changing services or exercising a workflow. No fixed fifteen-minute window establishes success.
Required outcome: [ ] Service, plan and enabled capability: [ ] Accounts, Regions and resource population: [ ] Prerequisites and configuration evidence: [ ] Approver, operating owner and cost owner: [ ] Verification type: [document review / sample delivery / posture check / authorized exercise] Expected observable result and limits: [ ] Downstream automation reviewed: [ ] Actual result, identifier and timestamps: [not performed / record] Acknowledgment and handling decision: [ ] What this did not establish: [ ] Next check and expansion condition: [ ]
Use the sample-finding precautions and task record below. Preserve the distinction between a proposed configuration, an observed result and a planned next step.
A sample finding tests routing, not threat detection
GuardDuty sample findings contain placeholder values and are marked [SAMPLE], with sample: true in additional information. Use them to check EventBridge matching, notifications, tickets, and acknowledgment. Successful delivery does not demonstrate that a real attack was detected or that all accounts and protection plans are covered.
Review downstream automation before generating samples. Route the test into an approved exercise workflow so placeholder resource details do not trigger an unintended production response. Record the account, Region, sample type, recipient, acknowledgment, and result. Exercise-based detection testing belongs in a separately authorized, isolated account. A proposed rollout schedule is only a planning aid; an urgent posture gap can justify prioritizing CSPM alongside detection.
Editorial review: 16 October 2026. Examples are illustrative; this review does not represent an audit or live control test.
AWS security-service outcome record
Use this when: you are a small team selecting detection or posture capabilities against a defined need. Copy the fields into your own notes. Record what is known, what remains uncertain and who will perform the next check.
| Field | What to record | Your evidence / next check |
|---|---|---|
| Required outcome | Describe the security question rather than starting with a service name. | To complete |
| Coverage boundary | Record accounts, Regions, resources and enabled capabilities. | To complete |
| Operational ownership | Assign triage, investigation, remediation and escalation responsibilities. | To complete |
| Validation boundary | Distinguish a routing sample from an actual detection or posture check. | To complete |
Next action: Choose the first capability whose findings your team can interpret and act on. Keep the supporting observation and its conditions beside the decision so that a later reader can distinguish an established result from a working explanation.
This is an editorial working aid. Complete it with your own scope, evidence and accountable reviewers; the table alone does not establish security, coverage or acceptance.
Related task: For CloudTrail evidence coverage and retrieval, use AWS CloudTrail Checklist: Coverage and Evidence. Keep that task distinct from the specific record above.
Worksheet change record — October 20, 2026
Added this aws security-service outcome record, four task-specific fields, a next action and a link to a distinct related task. Existing source notes keep their own review dates. This addition is not a new verification of every statement or a newly executed lab test.
Review notes, sources and limits
Document review: October 23, 2026. Replaced the universal GuardDuty-first sequence, team-size assumptions, staged product tiers and fixed-time rollout with outcome-specific checks. Current AWS service, pricing and sample-finding documentation informed the distinctions. No AWS account was accessed, service enabled, finding generated, cloud bill estimated or detection exercised for this review.
Sources: GuardDuty overview · CSPM overview · Security Hub service distinction · Current pricing scope · Sample findings and their limits