Operational guidance, not legal advice. This page distills named public sources (regulator guidance and industry practice). It is not a legal determination, not a notification decision, and not a substitute for your counsel, insurer, or a retained DFIR firm. Verify applicability and current deadlines for your facts and jurisdiction.
Which AWS artifacts count as security evidence?
Updated
CloudTrail evidences who did what, AWS Config evidences configuration state over time, IAM and Access Analyzer evidence authorisation, and Security Hub aggregates control status. AWS's own certifications cover the infrastructure layer, not your configuration. Not legal advice.
AWS evidence map, last verified 10 September 2026 against AWS public documentation for CloudTrail, AWS Config and conformance packs, IAM and IAM Access Analyzer, GuardDuty, Security Hub, AWS Audit Manager, KMS, S3 server access logging, and VPC flow logs, read alongside the CIS Amazon Web Services Foundations Benchmark, the AICPA Trust Services Criteria, and ISO/IEC 27001:2022 Annex A. AWS service names, console navigation, and packaging change frequently; AWS documentation is the authority. Nothing here is a determination that a framework applies to your organisation. This page does not determine YOUR obligations, does not start a clock, and does not file with an auditor.
What this page is, and what it is not
Audience: a platform engineer, security engineer, or compliance owner running workloads on AWS who needs to know which AWS artifact answers which audit question, and which questions AWS cannot answer for them.
This page is not legal advice. It does not determine YOUR obligations, does not decide which frameworks apply to your organisation, does not start a clock, and does not file anything with an auditor. An AWS service appearing next to a control is a mapping, not a conclusion that the control operated effectively. Last verified 10 September 2026.
The shared-responsibility model is the single most important framing on this page. AWS is responsible for security of the cloud — the hardware, the hypervisor, the managed-service control plane, the physical facilities — and publishes its own audit reports for that layer through AWS Artifact. You are responsible for security in the cloud: your identities, your network configuration, your encryption choices, your logging, your data. An AWS SOC 2 report is evidence about AWS. It is not evidence that your account is configured well, and an auditor will not accept it as such.
- Inheriting a control from AWS is legitimate and must be labelled. Record which controls you inherit, from which AWS report, and which complementary user-entity controls that inheritance depends on.
- Configuration evidence needs a period, not a snapshot. A console screenshot shows today; AWS Config configuration history and CloudTrail show the period an auditor is testing.
- Multi-account estates need estate-wide evidence. A single-account export from a twelve-account organisation is an incomplete population.
- Cost matters and shapes design honestly: CloudTrail data events, VPC flow logs, and Config recording all have volume-driven charges. Record the retention and scope choices you made and why.
Control-to-AWS-service map
Read the first column as the control assertion, the second as the AWS artifact, the third as where to find it, and the fourth as the framework note. Last verified 10 September 2026 against AWS documentation. Not legal advice.
| Control assertion | AWS artifact | Where it lives (console path or API) | Framework note |
|---|---|---|---|
| Administrative and API actions are recorded and attributable | CloudTrail management-event trail, organisation trail for multi-account estates, and CloudTrail Lake queries for the period | CloudTrail console → Trails; queries via CloudTrail console → Lake → Query, or the LookupEvents API. | AICPA TSC CC7.2; ISO/IEC 27001:2022 Annex A 8.15; NIST SP 800-53 Rev. 5 AU family. PCI DSS v4.0.1 Requirement 10 where cardholder data is in scope. |
| Log records cannot be altered by the people they describe | S3 bucket policy and Object Lock configuration for the CloudTrail destination, CloudTrail log-file validation enabled, and separate log-archive account ownership | S3 console → the log bucket → Properties (Object Lock) and Permissions; CloudTrail console → Trail detail → log file validation. | AICPA TSC CC7.2; Annex A 8.15; PCI DSS v4.0.1 Requirement 10.3 where in scope. |
| Resource configuration is known, recorded, and evaluated over time | AWS Config recorder status, configuration history and configuration timeline per resource, Config rule compliance history | AWS Config console → Settings for recorder status; Resources → resource timeline; Rules → compliance detail. | AICPA TSC CC7.1 and CC8.1; Annex A 8.9 configuration management; NIST SP 800-53 Rev. 5 CM family. |
| Configuration is measured against a named baseline | AWS Config conformance-pack deployment and its compliance report; Security Hub standard enablement and control findings | AWS Config console → Conformance packs; Security Hub console → Security standards → the enabled standard. | Conformance packs and Security Hub standards include packs and standards aligned to CIS, PCI DSS, and NIST references. Alignment is a mapping published by AWS, not a certification and not an auditor's conclusion. |
| Only authorised principals hold permissions, at least privilege | IAM credential report, IAM Access Analyzer findings for external access and unused access, role trust policies, permission boundaries and service control policies | IAM console → Credential report; IAM → Access Analyzer → Findings and unused access; Organizations console → Policies for service control policies. | AICPA TSC CC6.1–CC6.3; Annex A 5.15, 5.18 and 8.2; NIST SP 800-53 Rev. 5 AC family; PCI DSS v4.0.1 Requirements 7 and 8 where in scope. |
| Human access requires strong authentication and is not long-lived | IAM Identity Center configuration and assignment records, multi-factor status in the credential report, absence of long-lived access keys for human principals | IAM Identity Center console → Settings and Assignments; IAM → Credential report for key age and multi-factor columns. | AICPA TSC CC6.1; Annex A 5.17; PCI DSS v4.0.1 Requirement 8 where in scope. |
| Access reviews happen and are recorded | Periodic export of the credential report, IAM Access Analyzer unused-access findings, and Identity Center assignment listings, with a reviewer name and date attached | Exports from the paths above, stored in your evidence repository with reviewer and date. | AICPA TSC CC6.2–CC6.3; Annex A 5.18. Review cadence is your choice — see the IAM page in this cluster. |
| Threats are detected and triaged | GuardDuty enablement per account and region, findings history with disposition, and the detector configuration | GuardDuty console → Settings for enablement; Findings for history and archive status. | AICPA TSC CC7.2–CC7.3; Annex A 8.16; NIST SP 800-53 Rev. 5 SI-4. |
| Control status is aggregated and gaps are visible | Security Hub findings, control status per standard, and the aggregation configuration across accounts and regions | Security Hub console → Summary, Security standards, and Settings → Regions for aggregation. | AICPA TSC CC4.1 monitoring; Annex A 5.35 independent review as an input, not a substitute for it. |
| Data at rest is encrypted with managed keys, and key use is controlled | KMS key policies, key rotation configuration, S3 default-encryption settings, RDS and EBS encryption status, and CloudTrail records of key use | KMS console → Customer managed keys → key policy and rotation; S3 → bucket Properties → Default encryption. | AICPA TSC CC6.7; Annex A 8.24 use of cryptography; PCI DSS v4.0.1 Requirements 3 and 4 where in scope. |
| Object and network access is observable for investigation | S3 server access logs or CloudTrail data events for the buckets in scope, VPC flow logs, and Route 53 or DNS query logs where used | S3 → bucket Properties → Server access logging; VPC console → the VPC → Flow logs. | AICPA TSC CC7.2; Annex A 8.15 and 8.16; PCI DSS v4.0.1 Requirement 10 where in scope. |
| Backups exist, are protected, and restoration has been demonstrated | AWS Backup plan and job history, vault lock configuration, and a recorded restore test with date and outcome | AWS Backup console → Backup plans, Jobs, and Vaults → Vault Lock. | AICPA TSC A1.2–A1.3; Annex A 8.13 information backup and 5.29–5.30 continuity. The restore test is the evidence; the plan alone is not. |
| Framework-aligned evidence is collected on a schedule | AWS Audit Manager assessment reports and evidence folders for the selected framework | Audit Manager console → Assessments → the assessment → Evidence by control. | Audit Manager collects evidence against AWS-published framework mappings. Those mappings are AWS's interpretation, not certification and not an auditor's opinion. |
The shared-responsibility boundary, stated plainly
This is where most cloud evidence arguments happen. The line is not a matter of opinion for the services you use — AWS documents it per service — but where you sit on that line changes what you must evidence yourself. Last verified 10 September 2026. Not legal advice.
| Layer | Who evidences it | What you can and cannot rely on |
|---|---|---|
| Physical facilities, hardware, hypervisor, managed-service control plane | AWS, through its own SOC 2, SOC 1, ISO/IEC 27001, and PCI DSS attestations, available to customers via AWS Artifact. | You may inherit these controls and cite the AWS report. You must record the complementary user-entity controls the report lists, because those are yours. |
| Identity and authorisation in your accounts | You. AWS provides the mechanisms; the policies, roles, and reviews are your configuration. | An AWS certification says nothing about whether your root account has multi-factor authentication or whether an unused administrator role still exists. |
| Network configuration, encryption choices, logging, and retention | You, in almost every case. Some managed services encrypt by default; the choice, the key policy, and the retention are still yours. | Default-on behaviour still needs evidence that it is on in your accounts, for the period, for the resources in scope. |
| Patching | Split by service model. AWS patches the managed layer; you patch what you run on EC2 and in your containers. | Record the split per service you use, because an auditor will ask who patched what, and a generic answer fails. |
| Your data, its classification, and who may see it | You, entirely. | No AWS report and no conformance pack evidences a data-classification decision or a customer-facing access commitment. |
Legal requirement, guidance, best practice, or our recommendation
Cloud baselines are easy to mistake for law. Label the reason each control exists. Last verified 10 September 2026. Not legal advice.
| Statement | Which kind of authority | What it does not mean |
|---|---|---|
| PCI DSS v4.0.1 Requirements 3, 4, 7, 8 and 10 on encryption, access, and logging. | Legal requirement in the contractual sense, for entities in scope through card-brand and acquirer agreements. | Does not apply to an account with no cardholder data in scope, and does not mandate any AWS service by name. |
| NIST SP 800-53 Rev. 5 AC, AU, CM, and SI families. | Regulatory and standards guidance. Binding on US federal systems through separate authority such as FISMA and FedRAMP. | Does not bind a commercial company that has not contracted to it. |
| CIS Amazon Web Services Foundations Benchmark recommendations. | Industry best practice — a community consensus benchmark, published by the Center for Internet Security. | Not a law, not a certification, and not automatically appropriate in full for every architecture. Deviations are acceptable when recorded with a reason. |
| AICPA Trust Services Criteria and ISO/IEC 27001:2022 Annex A. | Attestation criteria and certification requirements, applying because you sought a report or certification, or a contract requires one. | Neither names an AWS service. The mapping in the table above is ours and yours, not theirs. |
| Deploy an organisation-wide CloudTrail to a dedicated log-archive account, enable AWS Config in every account and region in scope, and enable Security Hub with a named standard. | Industry best practice, and widely expected by auditors of a multi-account estate. | Not written as a requirement in any framework named here, and not a substitute for reviewing what the findings say. |
| Export the credential report, Access Analyzer unused-access findings, and Config conformance-pack status on a fixed cadence, with a named reviewer and date on each export. | ShipReady Metrics recommendation. | Does not make the control effective by itself, and is not required by any framework named here. |
Checklist
A question list for the AWS side of your evidence set. Not a determination that any framework applies to you. Last verified 10 September 2026. Not legal advice.
- Do we have the complete list of accounts and regions in audit scope, and is CloudTrail and AWS Config on in every one of them?
- Does the CloudTrail destination live in an account the workload teams cannot write to, with log-file validation on?
- Can we produce configuration state for a resource as it was three months ago, not only as it is today?
- Which conformance pack or Security Hub standard are we measured against, and is the current gap list dispositioned?
- Can we produce the credential report and Access Analyzer unused-access findings for the period, with reviewer names?
- Does the root user of every account have multi-factor authentication and no access keys?
- Which controls do we inherit from AWS, from which report, and have we recorded the complementary user-entity controls that inheritance depends on?
- Has a restore from backup actually been performed and recorded in the period, or do we only have a backup plan?
- Are GuardDuty and Security Hub findings dispositioned with a decision and an owner, or accumulating?
- Is the patching split between AWS and us written down per service we use?
What to do now
Ordered so the artifacts most often requested become producible first. None of these steps is a legal determination, and none files anything with an auditor.
- Establish the account and region scope list, and treat it as the population for every AWS control. Most cloud evidence findings are scope failures, not configuration failures.
- Turn on an organisation trail into a dedicated log-archive account with log-file validation, and record the retention and any data-event scoping decision with its reason.
- Enable AWS Config estate-wide and attach one conformance pack aligned to the framework you are actually pursuing. One pack that is reviewed beats three that are not.
- Enable Security Hub with a single named standard and cross-region aggregation, then work the gap list with owners rather than admiring the score.
- Schedule the credential report and Access Analyzer unused-access exports, and attach a named reviewer and date to each. That is your access-review artifact.
- Download the AWS reports you intend to inherit from via AWS Artifact, and write down the complementary user-entity controls they list against your own control set.
- Perform and record one restore test in the period. A backup plan without a restore record is the most commonly failed availability control.
- Re-verify AWS documentation for service behaviour and console paths annually, and record the date. Ours says 10 September 2026.
Where this shows up in ShipReady Metrics
Only shipped behaviour is described here. This product does not configure your AWS accounts, does not enable CloudTrail or Config for you, does not produce an auditor's opinion, and does not file anything with an auditor.
If you already have a session: signed-in app → Compliance holds evidence collection, which records control-mapped artifacts for starter control subsets, and evidence review, where a named human accepting a manual row renders it met and rejecting it renders it a gap, with a timestamp. Cloud configuration artifacts are typically manual rows reviewed that way. That overlay is a timestamped compliance artifact — not a forensic chain of custody, not a downloadable evidence binder, not a regulator filing pack, and not an auditor's opinion.
The obligation map lists frameworks your organisation marked in-scope. That mark is a scoping input you control, not a legal opinion that a framework applies. Readiness is an internal indicator, not certification.
Vulnerability management in this product ranks findings using CISA KEV membership, EPSS, and CVSS, deduplicates across sources, and supports blast-radius search over captured dependencies. Those are application and dependency findings, not AWS configuration assessments.
Primary sources (last verified 10 September 2026)
AWS documentation is the authority for every service behaviour and console path above; framework references are labelled by the kind of authority they carry.
AWS documentation for CloudTrail, AWS Config and conformance packs, IAM and IAM Access Analyzer, IAM Identity Center, GuardDuty, Security Hub, Audit Manager, KMS, S3 logging and Object Lock, VPC flow logs, AWS Backup, and AWS Artifact, together with the AWS shared-responsibility model. The CIS Amazon Web Services Foundations Benchmark is community best practice. AICPA Trust Services Criteria are attestation criteria. ISO/IEC 27001:2022 Annex A is a certification requirement set. NIST SP 800-53 Rev. 5 is guidance for commercial organisations. PCI DSS v4.0.1 binds entities in scope through contract. Not a complete list, and not legal advice.
The Azure and GCP pages in this cluster are the equivalent maps for those platforms. The IAM page covers the access lifecycle in depth, and the log-retention page covers how long to keep what these services produce.
Frequently asked questions
Is this legal advice?
No. It is an operational mapping of AWS artifacts to control assertions, with framework references labelled by the kind of authority they carry. Whether SOC 2, ISO/IEC 27001, PCI DSS, or any statute applies to your organisation is a legal and commercial question for counsel and your contracts. This page does not determine YOUR obligations and does not file anything with an auditor.
Can we use AWS's SOC 2 report as our evidence?
For the infrastructure layer AWS operates, yes — that is what inheritance means, and the report is available through AWS Artifact. For your configuration, no. AWS's report says nothing about whether your root accounts have multi-factor authentication, whether an unused administrator role exists, or whether your logs are retained. Record which controls you inherit and the complementary user-entity controls that inheritance depends on.
Does an AWS Config conformance pack make us SOC 2 or PCI DSS compliant?
No. A conformance pack is a set of Config rules AWS has mapped to a framework reference. Passing it means your resources satisfy those rules; it does not mean an auditor has tested your controls, and it does not cover the many controls that are not technical configuration at all — training, vendor management, change approval, policy governance. Treat it as a gap-finding tool.
Is a console screenshot acceptable evidence for AWS configuration?
Sometimes, for a setting that rarely changes, and it is the weakest option available on AWS. CloudTrail and AWS Config give you the same fact with a period and a source you did not hand-produce — configuration history shows what the resource looked like during the audit window, not only today. Prefer an API or Config export, and keep screenshots for narrative context.
Does ShipReady Metrics assess our AWS configuration?
It does not perform AWS configuration assessment. Cloud control evidence is handled as manual rows in evidence collection, where a named human accepting a row renders it met and rejecting it renders it a gap, with a timestamp. Vulnerability management in this product covers application and dependency findings from connected sources, ranked with KEV, EPSS, and CVSS. Nothing here replaces AWS-native assessment tooling.
Published by ShipReady Metrics, an evidence-based technology and compliance intelligence platform. This guide is educational and vendor-neutral.