Preparing for Compliance Audits with AWS CloudTrail (2026 Edition): Leaving the Audit Trail for PCI DSS, SOC 2, ISO 27001, and HIPAA as Tamper-Proof Evidence

One day, an audit firm or assessment body asks you this.

"Can you produce, in a tamper-free form, who accessed this customer data, when, with which permission, and from where?"

To this single question, can you answer immediately not with a screenshot of logs but with "cryptographically tamper-proof evidence"? That is the heart of regulatory response like PCI DSS, SOC 2, ISO 27001, and HIPAA. I designed and led the reliability layer of a serverless (Lambda + DynamoDB) payment platform and maintained 0 double charges in production, but the core of that discipline was designing, from the start, a state where "correctness can be proven later in a non-repudiable way." An audit trail isn't only for incident response. It's a device for proving "did / didn't" to a third party.

This article is a practical guide to designing AWS CloudTrail as audit evidence. CloudTrail's basic setup, initial Terraform construction, event types, and the basics of integrity validation are left to the CloudTrail Complete Guide (pillar article); here I dig in, narrowed to the single point of creating evidence you can present to a compliance audit.

The rules of this article: compliance carries legal weight. This article states requirement numbers, retention periods, and control IDs only within the range cross-checked against authoritative primary sources (PCI SSC / ISO / HHS / AWS official), and explicitly marks unconfirmed ones as "(verify)." This article is an explanation of implementation, not legal advice or a guarantee of audit pass/fail. Always confirm your own organization's compliance judgment with the original text of the relevant standard and the auditor, QSA, or assessment body you contract with.

0. Mental model: CloudTrail generates "evidence." But without configuration, it isn't evidence

First, fix the single line running through this entire article.

CloudTrail automatically generates the audit trail of "who, what, when, from where." But whether it becomes 'evidence' you can present to an auditor depends on the customer side's "configuration, storage, and review."

"Enabled CloudTrail = satisfied compliance" is the most common misconception in the field. A state with only CloudTrail enabled has holes that will definitely be poked in an audit.

That is, compliance response isn't "using CloudTrail cleverly" but "filling in all the conditions for it to hold as evidence." This article's structure is itself a checklist of those conditions.

0-1. The starting point of everything: the AWS Shared Responsibility Model

When talking with an auditor, this is the first map to share. Compliance is a division of labor between AWS and the customer, and CloudTrail belongs to its "customer side."

┌─────────────────── AWS Shared Responsibility Model ───────────────────┐
│                                                                       │
│  Customer's responsibility: Security IN the Cloud                     │
│  ├─ Which logs to collect (trail/data-event design)                   │
│  ├─ Where and how many years to store (S3 + Object Lock + lifecycle)  │
│  ├─ Encryption/access control (SSE-KMS / least privilege)             │
│  ├─ Log review (automating and recording daily review)                │
│  └─ Submitting evidence (packaging for the auditor)                   │
│  ── This is CloudTrail's domain. The target of this article ──        │
├───────────────────────────────────────────────────────────────────────┤
│  AWS's responsibility: Security OF the Cloud                          │
│  ├─ Physical data centers, hardware, hypervisor                       │
│  ├─ The foundation of managed services                                │
│  └─ AWS's own compliance certifications (SOC/PCI/ISO…)                 │
│  ── Obtain that proof with AWS Artifact (Chapter 5 later) ──          │
└───────────────────────────────────────────────────────────────────────┘

The official expression is clear — AWS = "security of the cloud," the customer = "security in the cloud." No matter how compliant the infrastructure AWS provides, if you design not logging, deletable, not reviewed on top of it, the audit doesn't pass. It's structurally impossible for CloudTrail to automatically satisfy compliance.

1. What the auditor demands: the 5 elements of the audit trail

Whatever the framework, the skeleton of requirements for audit logs is the same. What an auditor wants to know is, essentially, these 5.

A CloudTrail record holds exactly these 5 elements in structured JSON. Look at an actual record and you see the audit requirements mapped directly to fields.

{
  "eventTime": "2026-06-27T04:21:09Z",
  "eventSource": "s3.amazonaws.com",
  "eventName": "GetObject",
  "sourceIPAddress": "203.0.113.42",
  "userAgent": "aws-cli/2.x",
  "userIdentity": {
    "type": "AssumedRole",
    "arn": "arn:aws:sts::111122223333:assumed-role/PaymentOpsRole/alice",
    "accountId": "111122223333",
    "sessionContext": { "attributes": { "mfaAuthenticated": "true" } }
  },
  "requestParameters": { "bucketName": "cardholder-data-prod", "key": "txn/2026/...json" },
  "errorCode": "AccessDenied"
}

With this single record, you can answer the main questions of an audit. "alice, who assumed PaymentOpsRole, with MFA authenticated, from 203.0.113.42, tried to GetObject a specific object in the cardholder-data bucket and was denied." This is the minimum unit of "evidence."

What's decisively important here is that if you can't prove "this JSON hasn't been tampered with," its value as evidence collapses. Because it's over if the suspect denies it with "that log was rewritten later." How to create non-repudiation is handled in Chapter 3.

1-1. What separates "logs" from "evidence": the 3 conditions of audit eligibility

For the same CloudTrail record, whether an auditor can adopt it as evidence is decided not by the record's content but by the assurance surrounding it. What an auditor pokes in the field is always these 3 points.

Many teams are reassured with "we can record Who/What/When," but what fails an audit is usually one of these 3 conditions. The presence of the mechanism that protects the record, not the record's quality, divides pass/fail. After seeing the framework requirements in the next chapter, we fill all 3 conditions together in Chapter 3.

2. By framework: audit-log requirements and the CloudTrail correspondence

From here is the main subject. Let me correspond the "requirements related to audit logs" of the major 4 frameworks with how to satisfy them with CloudTrail.

An important premise: the following requirement numbers and retention periods are stated within the range of confirmable primary sources. Because the original texts of standards are revised, and also paid/copyright-protected, when citing for or judging your own organization's compliance, always confirm with the latest originals (the PCI SSC document library, the ISO/IEC originals, the eCFR, the AICPA TSC) and the auditor.

2-1. PCI DSS v4.0.1 — Requirement 10

PCI DSS Requirement 10 is "Log and Monitor All Access to System Components and Cardholder Data." It's the area where CloudTrail takes the most direct effect.

About the version: the effective version as of June 2026 is v4.0.1 (a limited revision published June 2024). v4.0 was retired at the end of December 2024, with no new establishment, deletion, or renumbering of requirement numbers. The 51 future-dated requirements were made mandatory on March 31, 2025.

About the handling of the numbers (verify): the above "12-month retention / the most recent 3 months immediately accessible (10.5.1)" and "daily review (10.4.1)" were consistently confirmable in multiple QSA-family sources and AWS's mapping, but for verbatim citation, finally confirm with the v4.0.1 original in the PCI SSC document library (copyright-protected, paid). The requirement numbers (10.4.1 / 10.5.1) and the substance can be treated as high-confidence.

What takes effect most in practice for PCI DSS response is reliably picking up access to "the system components that store, process, or transfer cardholder data." An S3 cardholder-data bucket isn't enough with management events alone, and you need to explicitly enable data events (object-level reads/writes) (since data events are billed from the 1st copy, narrowing the target bucket is the crux of cost design — see the pricing-optimization spoke).

2-2. SOC 2 — Trust Services Criteria

SOC 2 is not a certification but an "attestation" report by a CPA. There's no fixed "control list," and an auditor evaluates whether your organization's controls are effectively operated against the AICPA's "criteria" called the Trust Services Criteria (TSC). CloudTrail provides evidence for the following Common Criteria (CC) within it.

In SOC 2, rather than "satisfy control X," you say "your company's controls correspond to the criteria CC6/CC7/CC8." The criteria come with non-mandatory supplementary guidance called Points of Focus, but this isn't a checklist. The in-scope categories are chosen by the organization, but Security (the common criteria) is always mandatory.

CloudTrail's strength lies in the point that for SOC 2's Type II (operational effectiveness over a period), you can show "whether monitoring functioned throughout that period" with the continuity of the digest chain (Chapter 3). Being able to prove not only "I put in monitoring" but "monitoring kept running without interruption" takes effect in Type II response.

2-3. ISO/IEC 27001:2022 — Annex A (A.8.15 / A.8.16)

ISO/IEC 27001 had its Annex A reorganized in the 2022 edition. Logging and monitoring correspond to the following 2 controls.

About the control numbers: in the 2013 edition, there were 3 sub-controls (A.12.4.1–3) under the heading A.12.4 "Logging and monitoring." In the 2022 edition, A.8.15 "Logging" integrated them, and A.8.16 "Monitoring activities" was newly established. The numbers and titles were confirmed to match in multiple reliable sources, but final confirmation with the original (ISO/IEC 27001:2022, paid) is recommended. When citing, using the standard numbers "8.15 / 8.16" is accurate.

In ISO response, more than just "logging," the "protection of logs" A.8.15 requires (protection from tampering, deletion, and unauthorized access) is questioned. This is exactly where integrity validation + Object Lock comes in (Chapter 3).

2-4. HIPAA Security Rule — §164.312(b) Audit controls

HIPAA's (the U.S. medical-information-protection law's) Security Rule requires audit controls as a technical safeguard. This is a U.S. federal regulation (CFR) and is public domain, so it can be cited verbatim.

45 CFR §164.312(b) — Standard: Audit controls "Implement hardware, software, and/or procedural mechanisms that record and examine activity in information systems that contain or use electronic protected health information."

§164.312(b) is a "Standard (mandatory)" with no implementation specification (required/addressable). The text says only "implement a mechanism" and doesn't ask for a specific technology — that's exactly why you can satisfy it with the implementation of CloudTrail + automated review. Note that handling medical data on AWS presupposes a BAA (Business Associate Agreement) with AWS (out of this article's scope, verify on the contract side).

3. Create tamper-proof evidence: integrity validation + S3 Object Lock (WORM)

This is the technical core of this article. The difference between "there are logs" and "the logs are evidence" is decided by non-repudiation. Create this in 2 layers.

1. Cryptographic proof: log integrity validation (= mathematically show "this log hasn't been changed after delivery")
2. Physical immutability: S3 Object Lock compliance mode (= "no one can erase or overwrite it in the first place")

3-1. Layer 1: log integrity validation (SHA-256 / digest chain)

CloudTrail's log integrity validation is a mechanism that hashes with SHA-256 and signs with SHA-256 with RSA. It generates a digest file every hour, and each digest references the immediately preceding digest, forming a chain. This lets you detect changes/deletions of log files, and even prove that "not a single log was delivered in a certain period."

The official's non-repudiation expression is powerful.

"a validated log file enables you to assert positively that the log file itself has not changed, or that particular user credentials performed specific API activity. The CloudTrail log file integrity validation process also lets you know if a log file has been deleted or changed, or assert positively that no log files were delivered to your account during a given period of time."

In Terraform, just enable integrity validation at trail creation (for the basic configuration, see the pillar article; here only the key points).

resource "aws_cloudtrail" "compliance" {
  name                          = "org-compliance-trail"
  s3_bucket_name                = aws_s3_bucket.audit_logs.id
  is_multi_region_trail         = true
  enable_log_file_validation    = true   # ← これが整合性検証(digest)の有効化
  kms_key_id                    = aws_kms_key.audit.arn
  include_global_service_events = true
}

In an audit, before submission, running the validation yourself and attaching the result to the evidence too takes effect.

# 指定期間のログ整合性を検証（digestチェーンをたどって改ざん有無を判定）
aws cloudtrail validate-logs \
  --trail-arn arn:aws:cloudtrail:ap-northeast-1:111122223333:trail/org-compliance-trail \
  --start-time 2026-04-01T00:00:00Z \
  --end-time   2026-06-27T00:00:00Z \
  --region ap-northeast-1

An operational caveat: validate-logs validates the logs in their original location on S3. A file downloaded locally can't be validated this way. It's also a per-region validation, so --region takes effect. Build into your operational routine "run validate-logs quarterly and store the result as evidence."

3-2. Layer 2: S3 Object Lock compliance mode (WORM)

Integrity validation is a mechanism that "can detect tampering," but if an attacker or insider deletes the log itself, you can detect but the evidence is lost. So create storage that's un-deletable in the first place. That's S3 Object Lock's WORM (Write Once Read Many) model.

Object Lock has 2 modes.

For an audit trail, Compliance mode is the real choice. The official states — in compliance mode, a protected object version cannot be overwritten or deleted by any user, including the root user, and the retention mode can't be changed nor the retention period shortened. That there's no loophole of "a privileged administrator can delete it." This is the decisive reassurance for an auditor.

In addition, there's a Legal Hold. It's independent of the retention period, and is for "not letting it be deleted even after the period expires" during litigation or investigation. It's effective indefinitely until removed.

The implementation HCL. Object Lock presupposes versioning enabled, and is typically enabled at bucket creation.

# 1) 監査ログ専用バケット（Object Lock を作成時に有効化）
resource "aws_s3_bucket" "audit_logs" {
  bucket              = "org-audit-logs-immutable-111122223333"
  object_lock_enabled = true   # ← バケット作成時に有効化が前提

  # 監査ログの誤削除を二重に防ぐ
  lifecycle {
    prevent_destroy = true
  }
}

# 2) バージョニング（Object Lock の必須前提）
resource "aws_s3_bucket_versioning" "audit_logs" {
  bucket = aws_s3_bucket.audit_logs.id
  versioning_configuration {
    status = "Enabled"
  }
}

# 3) Object Lock 既定保持ルール：コンプライアンスモードで例えば 365 日
#    （保持年数は2-1のPCI 10.5.1等、適用フレームワークの要求に合わせる）
resource "aws_s3_bucket_object_lock_configuration" "audit_logs" {
  bucket = aws_s3_bucket.audit_logs.id
  rule {
    default_retention {
      mode = "COMPLIANCE"   # GOVERNANCE ではなく COMPLIANCE
      days = 365            # ← 適用要件に合わせて設定。短縮不可なので慎重に
    }
  }
}

# 4) SSE-KMS で暗号化（保管中の機密性）
resource "aws_s3_bucket_server_side_encryption_configuration" "audit_logs" {
  bucket = aws_s3_bucket.audit_logs.id
  rule {
    apply_server_side_encryption_by_default {
      sse_algorithm     = "aws:kms"
      kms_master_key_id = aws_kms_key.audit.arn
    }
    bucket_key_enabled = true
  }
}

# 5) パブリックアクセスは全面ブロック
resource "aws_s3_bucket_public_access_block" "audit_logs" {
  bucket                  = aws_s3_bucket.audit_logs.id
  block_public_acls       = true
  block_public_policy     = true
  ignore_public_acls      = true
  restrict_public_buckets = true
}

A design pitfall (important): compliance mode's days can't be shortened. Intend "365 days" in a test and let it flow to production, and that object becomes un-deletable by anyone for a year. Validate with a very short retention in staging, and fix the production value by working backward from the applicable framework's retention requirement (PCI 10.5.1 in 2-1, etc.).

Incompatibility with MFA Delete (official spec): AWS officially states "MFA Delete and lifecycle configuration can't be used together." CloudTrail's best practices recommend both MFA Delete and lifecycle, but they're incompatible on the same bucket. In practice, split into "the immutable raw-log bucket = Object Lock" and "archive/transition = a separate bucket with lifecycle," or unify on Object Lock — that's the standard play. This article centers on Object Lock.

If you step into the centralization of audit-log buckets (concentrating into a log-archive account), see Organization Trail / Multi-Account Audit. Apply Object Lock to the destination bucket.

4. Satisfy the storage requirement: designing the retention period and cost

Once you've made it "tamper-proof," next is "keep it for the prescribed number of years." Design this with the multiplication of the framework's retention requirement and S3's storage classes / lifecycle.

4-1. Work the retention period backward from the requirement

In short, unifying to "the longest requirement" is operationally simple. In many regulated industries, lean to "at least 12 months, multiple years on the safe side." The days decided in Object Lock's compliance mode is the physical guarantee of this retention.

4-2. Keep costs down with lifecycle

The structure of PCI 10.5.1's "the most recent 3 months immediately accessible, retained after that up to 12 months" maps directly to S3's storage classes.

# 注意: Object Lock バケットと MFA Delete は併用不可。
# ここは「Object Lock で不変性を担保しつつ、コスト最適化のため階層移行」する例。
resource "aws_s3_bucket_lifecycle_configuration" "audit_logs" {
  bucket = aws_s3_bucket.audit_logs.id

  rule {
    id     = "tiered-retention"
    status = "Enabled"

    # 直近: S3 標準（即時アクセス）
    transition {
      days          = 90               # ~3ヶ月は標準（PCIの即時アクセス相当）
      storage_class = "GLACIER_IR"     # 90日以降は低頻度アクセス向けに移行
    }
    transition {
      days          = 180
      storage_class = "DEEP_ARCHIVE"   # 長期は最安アーカイブへ
    }
    # expiration は設定しない（Object Lock の保持が満了管理を担う）
  }
}

The cost deep dive goes to a separate article: the estimation of long-term-storage tiers, retrieval cost, and data-event billing is consolidated in the CloudTrail Pricing & Cost-Optimization Guide. This article grasps only the mapping of "retention requirement → storage design."

Don't use CloudTrail Lake for new builds: there's also a way to use CloudTrail Lake (up to 3,653 days ≒ 10 years) for long-term retention, but Lake has ended new-customer acceptance as of May 31, 2026 (existing customers can continue). For new builds, S3 + Object Lock + lifecycle is the realistic and future-safe choice.

5. Automate evidence collection: Config / Artifact (and the current state of Audit Manager)

Even if you correctly accumulate logs, in an audit the step of "systematically collecting and presenting it as evidence" remains. AWS has services that support this, but note the provision status as of 2026.

5-1. Continuously evaluate "configuration" with AWS Config Conformance Packs

If CloudTrail is "a record of operations," AWS Config is the continuous evaluation of "whether the configuration keeps satisfying the requirements." AWS provides sample Conformance Packs by regulation.

• Operational Best Practices for PCI DSS (PCI DSS 3.2.1 / 4.0 versions available)
• Operational Best Practices for HIPAA Security
• Other templates like NIST and CIS

These continuously evaluate and detect drift of "is CloudTrail enabled," "is log integrity validation ON," "are S3 buckets encrypted and public-blocked," etc.

# サンプル Conformance Pack（PCI DSS）をデプロイする例
aws configservice put-conformance-pack \
  --conformance-pack-name pci-dss-operational-best-practices \
  --template-s3-uri s3://aws-sample-conformance-packs/Operational-Best-Practices-for-PCI-DSS.yaml \
  --delivery-s3-bucket org-config-conformance-results

AWS's note (important): AWS itself explicitly states these are sample templates and "don't fully guarantee compliance with a specific standard." Use them as a "tool to find holes early with automated evaluation," on the premise that the final compliance judgment is made by the auditor. The details of the division of roles between Config and CloudTrail go to CloudTrail vs CloudWatch vs Config Usage Distinction.

5-2. Obtain "AWS-side certificates" with AWS Artifact

The proof of the AWS side of the shared responsibility model (Chapter 0-1) is not something the customer creates but is downloaded from AWS. That's AWS Artifact. Artifact provides AWS's compliance documents on demand — SOC reports, PCI (DSS)-related reports, ISO certifications, etc.

When an auditor asks "does AWS properly hold certifications," obtain the relevant document with Artifact and submit it. This becomes the evidence that "the infrastructure layer is compliant on AWS's part."

A note to verify: the Artifact official page explicitly states "ISO, PCI, SOC reports," but the individual document names "SOC 1/2/3" and "PCI DSS AOC (Attestation of Compliance)" aren't verbatim-listed on that page. In reality these are provided, but confirm the exact document names in the Artifact console.

5-3. The current state of AWS Audit Manager (new-customer acceptance ended)

AWS Audit Manager was originally a service that, selecting a framework, automatically collects user-activity evidence with CloudTrail as the evidence source — exactly fitting this article's context (with standard frameworks including PCI DSS / SSAE-18 SOC 2 / ISO 27001:2013 Annex A / HIPAA / GDPR / CIS / NIST / FedRAMP, etc.).

However (important, high impact to verify): the AWS official documentation currently displays a banner that "AWS Audit Manager has ended new-customer acceptance (Existing customers can continue to use the service as normal)." You can't count on it for new builds. Only organizations with existing use can continue. For new builds, the realistic 2026 solution is to substitute with "Config Conformance Pack (automated evaluation) + Artifact (AWS-side proof) + CloudTrail (the trail) + your own evidence packaging (Chapter 6)." Audit Manager's standard framework names (e.g., SSAE-18 SOC 2) are confirmed, but grasp first and foremost that it's unavailable for new use.

6. The practice of audit response: automating daily review and the submission package

Finally, the practice of "leaving the trail of having reviewed" and "presenting to the auditor." PCI 10.4.1 (daily review) and HIPAA §164.312(b)'s "examine" can't be satisfied by just accumulating logs. A record of "the review was conducted" itself is needed.

6-1. Automate daily review (EventBridge / CloudWatch)

"A person visually inspects every day" breaks down. Design it so that high-risk API activity is detected and notified, and the record of that notification and response itself becomes the review trail.

// EventBridge ルール例：監査ログ保護に関わる危険操作を即時検知
// （CloudTrail → EventBridge。CloudTrail自体の停止・KMS鍵の無効化・Object Lock関連の不正操作を監視）
{
  "source": ["aws.cloudtrail", "aws.kms", "aws.s3"],
  "detail": {
    "eventName": [
      "StopLogging",
      "DeleteTrail",
      "UpdateTrail",
      "DisableKey",
      "ScheduleKeyDeletion",
      "PutBucketObjectLockConfiguration",
      "DeleteBucketPolicy"
    ]
  }
}

Flow this rule to Lambda/SNS and connect it to Slack/email + ticket filing, and "when what was detected, and who responded how" is automatically recorded. This becomes the evidence that "daily review was conducted with an automated mechanism (PCI 10.4.1.1)."

The trick is to monitor, with top priority, "operations related to protecting the audit logs (stopping CloudTrail, deleting KMS keys, changing Object Lock)." Because operations that neutralize the audit trail itself are exactly where attackers and insiders aim first. The system of threat detection and incident response (GuardDuty/CIS integration) goes to Threat Detection & Incident Response with CloudTrail. Compliance (= evidence preservation) and threat detection (= finding attacks) are complementary, different things.

6-2. Create the submission package for the auditor

The "submission package" valued in an audit is roughly the following composition.

# ①証跡ステータス（録っているか・整合性検証ONか）
aws cloudtrail get-trail-status --name org-compliance-trail

# ③バケットの不変性（Object Lock 設定）
aws s3api get-object-lock-configuration --bucket org-audit-logs-immutable-111122223333

The strength of this package lies in the point that ① through ⑥ are all mechanically reproducible (re-obtainable with one command). Rather than a hodgepodge of screenshots, creating "a state where you can regenerate the same evidence anytime" — this is the reality of "a state where correctness can be proven later in a non-repudiable way."

7. Summary: the compliance-audit response checklist

The final checklist for promoting CloudTrail to "audit evidence."

• Share the shared responsibility model: agree with the auditor that the AWS-side proof is Artifact, and the customer side (logging, retention, review) is your responsibility
• Create a Trail: don't rely on event history (90 days, management events only); create a multi-region trail
• Data events for the target data: enable data events for S3 etc. storing cardholder data / ePHI
• Log integrity validation ON: enable_log_file_validation = true. Run validate-logs quarterly and store the result
• S3 Object Lock compliance mode: WORM storage not even root can erase (versioning premised, retention days worked backward from the requirement)
• SSE-KMS + public block + least privilege: confidentiality and access control
• Retention period: match the longest requirement of the applicable framework (PCI is 12 months / the most recent 3 months immediate: after verifying). Optimize cost with lifecycle
• Daily/automated review: detect dangerous operations (stopping the trail, deleting KMS, changing Object Lock) with EventBridge, and make the response record the review trail
• Continuous evaluation: detect configuration drift with AWS Config Conformance Packs (PCI/HIPAA, etc.)
• AWS-side proof: obtain the relevant report from AWS Artifact
• Submission package: arrange ① through ⑥ in a form regenerable with commands
• Avoid deprecated services: Audit Manager and CloudTrail Lake have ended new-customer acceptance. For new builds, assemble with alternatives

And finally, the most important principle.

CloudTrail is not a tool that "automatically satisfies" compliance. It's a tool that generates the audit trail of "who, what, when, from where, succeeded or failed." Only when the customer takes on the design of storing it tamper-proof, retaining it for the prescribed years, and leaving a record of having reviewed it does it become "evidence" you can present to an auditor. Weave the "customer side" of the shared responsibility model into the design from the start. That is the essence of an AWS audit foundation in a regulated industry.

In designing and leading the reliability layer of a payment platform, I made it a discipline to create, from the start, "a state where correctness can be proven later to a third party in a non-repudiable way." The audit trail is that discipline dropped into the infrastructure.

For regulatory response like PCI DSS, SOC 2, ISO 27001, and HIPAA, if you have the challenge of wanting to design an AWS foundation equipped with a tamper-proof audit trail, consult via Contact. From organizing the shared responsibility model to designing and implementing an evidence foundation with CloudTrail + Object Lock + Config + Artifact, I help end-to-end.