Skip to content

AWS Updated 2026-07-04

AWS compliance support: producing the evidence auditors and clients actually ask for

AWS compliance support is mostly evidence production: access reviews, change history, backup proof, encryption attestations. Here is what Law 25 and SOC 2 conversations actually require from your AWS environment, and how to produce it without a scramble.

Compliance work on AWS is mostly evidence production. Whether the request comes from a SOC 2 auditor, a big client’s security questionnaire, or a Quebec Law 25 review, the questions converge on the same short list: who has access and who reviewed it, what changed and when, are backups running and tested, is data encrypted, where does the data live, and what happens when something goes wrong. An AWS environment that is operated well can answer all of these from tooling that is already running; an environment that is not becomes a two-week scramble every time the questionnaire arrives. One note before anything else: this article is about producing technical evidence — it is not legal advice, and Law 25 or SOC 2 scoping decisions belong with your legal and audit advisors.

What you are deciding

The decision is whether compliance evidence is a byproduct of how you operate, or a project you rerun every time someone asks. The second mode is the default and it is miserable: screenshots assembled by hand, IAM lists pasted into spreadsheets, a backup “policy” written the week the auditor asked. The first mode means the systems of record are on all the time — CloudTrail as the change ledger, AWS Config as the configuration history, AWS Backup as the recovery evidence, IAM and Identity Center as the access record — and answering an auditor becomes an export, not an investigation.

It helps to be precise about what each framework wants from the AWS layer. SOC 2 Type II looks for controls operating over a period — so a single hardening snapshot is worth little, and a year of CloudTrail, quarterly access-review records, and dated restore-test logs are worth a lot. Law 25 is Quebec privacy law: it expects safeguards proportional to data sensitivity, a confidentiality-incident register, and an assessment before personal information is communicated outside Quebec — which is why Canadian workloads holding personal information usually standardize on ca-central-1 and document any service that processes data elsewhere. And one boundary saves endless confusion: AWS’s certifications cover their side of the shared responsibility model. You inherit them for the infrastructure layer — you download the attestations from AWS Artifact (docs) — but nothing AWS publishes attests your IAM hygiene, your backup testing, or your incident process. That part is always yours.

What to check first

  • Is the evidence machinery on? CloudTrail logging continuously (with log file validation), Config recording in the regions you use, backup jobs succeeding. If any of these has gaps, your evidence period starts when you fix it — a reason to fix it today.
  • Log retention versus audit period. A Type II audit covers up to a year; CloudTrail delivering to S3 with lifecycle rules shorter than that is a finding waiting to happen.
  • Where personal information actually lives. Region per data store, including the forgotten ones: S3 replicas, snapshot copies, third-party integrations.
  • Whether access reviews have ever happened. Auditors ask for the review records, not just the current IAM state.
  • The incident register. Law 25 expects confidentiality incidents to be logged and assessed; if the register does not exist, that is a gap no AWS tool fills.

How to verify

Confirm the systems of record are actually recording:

# CloudTrail: logging, validated, and multi-region?
aws cloudtrail describe-trails \
  --query 'trailList[].[Name,IsMultiRegionTrail,LogFileValidationEnabled]'
aws cloudtrail get-trail-status --name org-trail --query '[IsLogging,LatestDeliveryTime]'

# Config: recorder on, delivering?
aws configservice describe-configuration-recorder-status
aws configservice describe-delivery-channel-status

# Backup evidence: completed jobs and restore tests
aws backup list-backup-jobs --by-state COMPLETED --max-results 20
aws backup list-restore-jobs --max-results 10

Spot-check the encryption story auditors always ask about:

# Encryption at rest, per data store
aws rds describe-db-instances \
  --query 'DBInstances[].[DBInstanceIdentifier,StorageEncrypted]'
aws s3api get-bucket-encryption --bucket prod-data-bucket

For the AWS-side attestations, AWS Artifact > Reports in the console is where you download AWS’s SOC reports and other certifications to hand to your auditor — that download is the entirety of the “inherited” evidence.

The approach

  1. Turn on the ledgers before anything else. Organization CloudTrail with log file validation, delivering to a dedicated log-archive account with retention beyond your audit period; Config recording where workloads live. The CloudTrail and GuardDuty baseline is the concrete setup.
  2. Make access reviews a recurring calendar event, and keep the artifacts. Quarterly: export the IAM credential report and Identity Center assignments, have the owner of each system confirm the list, record the sign-off (a dated document in a controlled location is fine). The record of the review is the evidence — the review without a record did not happen, as far as an audit is concerned.
  3. Turn backups into recovery evidence. Backup job history plus dated, timed restore-test logs. A cross-region or cross-account copy strengthens both the resilience story and the evidence; the mechanics are in AWS Backup with cross-region copy.
  4. Write the data map. One page per system: what personal or sensitive data, which AWS services, which regions, what leaves Canada and why. This single artifact answers half of every security questionnaire and is the starting point for Law 25 transfer assessments your advisors will run.
  5. Stand up the incident path. A register (even a disciplined spreadsheet), a severity rubric, and GuardDuty findings wired to a human so detection feeds the register. Auditors ask “show me the last incident and what you did” — a boring, well-documented small incident is a great answer.
  6. Automate the recurring exports. Config rules or Security Hub controls mapped to your framework’s criteria give you continuously-collected pass/fail history instead of a quarterly screenshot hunt. AWS Audit Manager can assemble framework-shaped evidence packages; it is worth evaluating once the manual process works and its cost (per-assessment resource evaluation) is justified by audit frequency.

When this is the wrong move

If nobody has actually asked — no client questionnaire, no audit on the calendar, no personal-information processing that triggers Law 25 obligations — build the operational baseline (logging, backups, access hygiene) for its own sake and skip the framework-shaped paperwork until there is a real driver; evidence machinery without a consumer is just process weight. Conversely, if a SOC 2 Type II deadline is under three months away and none of the ledgers are running, be honest about sequencing: the observation period needs the controls operating first, and a consultant promising retroactive evidence is promising something the model does not allow. And do not buy tooling to solve a paperwork problem — an environment with no access reviews does not need an audit platform; it needs someone to run the review.

Common mistakes

  • Pointing at AWS’s certifications as your own. “AWS is SOC 2 certified” answers the data-centre question only; the auditor’s next question is about your controls, and Artifact PDFs do not cover those.
  • Evidence with gaps in the timeline. A trail that was off for three weeks in March turns into an audit exception; alarm on StopLogging and on delivery failures.
  • Reviews that leave no artifact. Verbal quarterly reviews, Slack-thread approvals, undated exports — if it is not dated and retrievable, it does not exist at audit time.
  • A data map that omits copies. Snapshots shared to another account, replicas in a second region, and analytics exports are all “where the data lives” answers waiting to surprise you.

Keeping it under control

  • Calendar the quarterly access review and the quarterly restore test; store both artifacts in one controlled location.
  • Alarm on the evidence machinery itself: CloudTrail stopped, Config recorder off, backup job failures.
  • Refresh the data map whenever a new service or region enters production — tie it to the change process, not to memory.
  • Keep retention settings (CloudTrail, Config, backups) explicitly longer than the audit period.
  • Re-download current AWS Artifact reports before each audit cycle rather than reusing last year’s.

Teams that operate this way stop fearing questionnaires — the answers are exports from systems that were already running. If nobody on your team truly owns the AWS environment end to end, that is the root of most of these problems — Stack Harbor runs AWS accounts daily under AWS Operations, and you can book an AWS review.