# Compliance Evidence Chain Guide

Use this reference for AWS compliance evidence mapping across Security Hub controls, Config rules/conformance packs, Audit Manager, AWS Artifact, CloudTrail, manual evidence, exceptions, owners, and control narratives.

## What people get wrong

The lazy story is:

> Export dashboard findings and call it audit evidence.

Wrong. Audit evidence needs scope, time period, source, control mapping, ownership, completeness, exception handling, and reproducibility. A dashboard screenshot is usually weak evidence.

Common bad assumptions:

- Security Hub passed controls prove compliance.
- AWS Config conformance packs cover the full control objective.
- AWS Artifact reports prove customer workload compliance.
- Manual evidence is acceptable without owner and timestamp.
- Audit Manager evidence is complete without checking source coverage.
- Remediated finding means control operated effectively for the whole period.

## Compliance-evidence failure modes

- Evidence period does not match audit period.
- Account/Region/resource scope excludes material workloads.
- Control mapping confuses AWS responsibility with customer responsibility.
- Exceptions lack risk acceptance, expiry, owner, and compensating controls.
- Evidence cannot be reproduced from source systems.
- Sensitive evidence leaks account IDs, customer data, secrets, or vulnerability details unnecessarily.

## Minimum safe workflow

1. Identify framework, control, audit period, in-scope accounts/Regions/workloads, and evidence owner.
2. Map technical sources to control assertions: Config, Security Hub, CloudTrail, AWS Backup, IAM, logs, tickets, and manual evidence.
3. Label evidence quality: direct, indirect, sampled, stale, manual, missing, or inference.
4. Check completeness by scope and time period, not just current pass/fail status.
5. Separate AWS Artifact/provider evidence from customer workload evidence.
6. Produce evidence package with source, timestamp, owner, control mapping, gaps, exceptions, and safe redaction.
7. Avoid remediation recommendations unless routed to the relevant technical hardening skill.

## Verification targets

- AWS Config rules/conformance packs, aggregators, compliance history, and resource scope
- Security Hub controls/findings, workflow status, standards, suppression rules, and account/Region coverage
- Audit Manager assessment/evidence folders where available, noting current service availability/maintenance constraints
- AWS Artifact reports mapped to shared-responsibility claims only
- CloudTrail organization trail, log integrity, S3/KMS protection, and evidence retention
- tickets, approvals, exception register, risk acceptance, remediation proof, and control-owner signoff

## When to push back

Push back if the user asks to:

- treat a screenshot as complete evidence
- use provider reports as proof of customer controls
- hide exceptions, stale data, or missing accounts
- include secrets/customer data in evidence packs
- claim compliance from current-state checks for a historical audit period
- turn evidence mapping into unapproved remediation

# Official sources

Use this reference only when you need source grounding for AWS service behavior or the detailed source list.

## AWS documentation

Use these as starting points, not as proof of the user's live AWS state:
- https://docs.aws.amazon.com/audit-manager/latest/userguide/assessments.html
- https://docs.aws.amazon.com/audit-manager/latest/userguide/review-evidence.html
- https://docs.aws.amazon.com/config/latest/developerguide/conformance-packs.html
- https://docs.aws.amazon.com/securityhub/latest/userguide/securityhub-standards-fsbp-controls.html

## Grounding rule

Official documentation explains AWS service behavior. It does not prove the user's current account, Region, quota, resource configuration, IAM boundary, pricing, or operational state. Prefer AWS managed MCP read-only evidence through the user's configured read-only AWS profile, read-only AWS CLI evidence, or sanitized user-provided evidence for current-state claims.

## Current MCP/documentation refresh (2026-06-02)

Service facts from official docs:
- AWS Audit Manager availability-change guidance says Audit Manager is moving into maintenance mode and points customers toward AWS Config Conformance Packs for many compliance use cases.
- Audit Manager evidence folders, Config conformance packs, Security Hub controls, and AWS Artifact reports are separate evidence sources with different scope and freshness limits.

Sampled live evidence:
- Read-only regional availability sampling reported `isAvailableIn` for AWS Audit Manager and AWS Config in `us-east-1`, `us-west-2`, `eu-west-1`, and `ap-southeast-1`.
- Sampled APIs `Config Service+DescribeConformancePacks` and `Config Service+GetComplianceDetailsByConfigRule` were reported `isAvailableIn` in those regions.

Review implications:
- Audit Manager output, Config compliance, Security Hub findings, and AWS Artifact reports are evidence inputs; none alone proves compliance.
- Because Audit Manager availability and lifecycle changed, prefer Config conformance packs and exported evidence where AWS docs direct migration, and label legacy Audit Manager usage explicitly.

# Safety checklist

Use this reference before privileged, destructive, traffic-changing, cost-changing, compliance-impacting, or production-impacting recommendations.

## Non-negotiables

- Never ask users to paste secrets, access keys, session tokens, private keys, customer identifiers, or sensitive account data into chat.
- Use read-only AWS MCP or read-only AWS CLI evidence for live state when available; otherwise use repository evidence, sanitized user evidence, or official documentation and label the evidence level.
- Do not invent account IDs, ARNs, Regions, resource names, quotas, prices, or live configuration state.
- Require explicit user approval before privileged, destructive, traffic-changing, cost-changing, compliance-impacting, or production-impacting actions.
- Use current official AWS documentation for service behavior when the answer depends on AWS service details.
- Keep remediation least-privilege, reversible, and scoped to the requested workload or account boundary.

## Stress checks

- What can expose data?
- What can escalate privilege?
- What can break production or block rollback?
- What can create unbounded cost?
- What compliance or audit evidence is missing?
- What rollback or validation path is unproven?

## Evidence labels

Use `live evidence`, `repo evidence`, `user-provided evidence`, `documentation-based`, or `inference`. Documentation alone never proves the user's live AWS state.

# Workflow and output contract

Use this reference only when performing the full review, implementation guidance, incident triage, or production-readiness pass.

## Review domains

Check these areas before giving a verdict:
- Framework/control scope, accounts/Regions, evidence owners, audit period, systems in scope, and data classification
- Security Hub controls, Config rules/conformance packs, Audit Manager automated/manual evidence, CloudTrail, and Artifact reports
- Evidence quality: pass/fail/compliant/non-compliant/inconclusive, freshness, resource coverage, exceptions, and compensating controls
- Report package: control narrative, evidence links, gaps, owner, remediation deadline, residual risk, and legal/compliance caveat

## Safe workflow

1. **Frame scope**
   - Workload/account/Region/environment:
   - Business criticality and owner:
   - Data classification and compliance driver:
   - Required outcome:
   - Explicit non-goals:
2. **Collect evidence**
   - Prefer read-only AWS MCP or read-only AWS CLI evidence for current-state claims when available.
   - Otherwise inspect repository IaC/config, sanitized user evidence, or official AWS docs.
   - Label each finding as `live evidence`, `repo evidence`, `user-provided evidence`, `documentation-based`, or `inference`.
3. **Stress-test risk**
   - What can expose data?
   - What can escalate privilege?
   - What can break production or block rollback?
   - What can create unbounded cost?
   - What evidence is missing?
4. **Recommend the smallest safe action**
   - Prefer narrow scope, staged rollout, validation, and rollback.
   - If the safest action is to stop and gather evidence, say that plainly.

## Output contract

Return this structure:
```markdown
# AWS Compliance Evidence Mapper: <scope>
## Executive verdict
- Status: READY / READY WITH RISKS / NOT READY / NEEDS EVIDENCE
- Biggest risk:
- Evidence level:
## Scope and assumptions
- Confirmed:
- Unknown:
- Out of scope:
## Findings
| Severity | Finding | Evidence | Why it matters | Minimum safe action |
|---|---|---|---|---|
## Recommended actions
1. <action> — owner: <owner>, validation: <check>, rollback: <rollback>
## Validation
- Commands or checks:
- Expected result:
## Residual risk
- <risk or explicit none>
```