Sync Your Cloud
Sync Your Cloud

🍪We value your privacy

We use cookies to enhance your browsing experience, analyse site traffic, and personalise content. Choose your preferences below.

Essential CookiesRequired

Required for the website to function properly. These cannot be disabled.

Functional CookiesOptional

Enable personalised features like remembering your preferences and settings.

Cookie PolicyPrivacy Policy
Home/Insights/ADRs as PCI DSS Audit Evidence
PCI DSS 4.0.1 · Audit Evidence

PCI DSS Architecture Decision Records as Audit Evidence

Architecture Decision Records are a development practice. In a PCI DSS assessment, they are something more: contemporaneous, version-controlled evidence of why security decisions were made, when they were made, and who approved them. A QSA who understands ADRs can extract months of compliance evidence from a well-maintained ADR corpus. A QSA who ignores them leaves a major evidence source untapped.

13 min read PCI DSS 4.0.1 Audit Evidence

What Is an Architecture Decision Record?

An Architecture Decision Record (ADR) is a short document that captures a single architectural decision, the context that led to it, the options considered, the decision made, and its consequences. Originally proposed by Michael Nygard, ADRs are stored in version control alongside the codebase — giving them a timestamp, an author, and an approval trail via pull request review.

For PCI DSS purposes, three properties make ADRs uniquely valuable as audit evidence:

Contemporaneous record
ADRs are written at the time the decision is made — not reconstructed for the assessment. A QSA can verify the commit timestamp against the infrastructure change, establishing that the decision was documented before, not after, implementation.
Version controlled
The Git history of an ADR shows who authored it, who reviewed it (via PR approvals), and whether it was subsequently superseded. This satisfies change management evidence requirements without additional process.
Decision rationale captured
PCI DSS increasingly requires evidence of "why" — why a control was chosen, why a risk was accepted, why a compensating control was deemed equivalent. ADRs capture this reasoning in a form a QSA can review and reference.

PCI DSS Sub-Requirements Satisfied by ADRs

The following table maps specific PCI DSS 4.0.1 sub-requirements to the ADR content that satisfies them. Not every ADR satisfies every requirement — but a mature ADR corpus covering security-relevant decisions provides substantial evidence across multiple domains.

Sub-reqRequirement text (summary)ADR content that satisfies itWhat QSA verifies
6.3.1Vulnerabilities identified and assessed; security patches appliedADR documenting decision to apply a patch, version upgrade, or library replacement — including the vulnerability it addressed and the test evidenceADR timestamp precedes or is contemporaneous with deployment; PR reviewer is a named approver
6.5.1Change control process for all changes to system components in scopeADR linked to the change ticket; PR requiring approval before merge to production branchADR corpus covers all in-scope component changes; no production change exists without a corresponding ADR
6.5.6Test/dev data not used in productionADR documenting decision to separate test and production environments, including the controls that enforce separationADR describes enforcement mechanism — not just intent; separate AWS accounts or SCPs documented
2.2.1System components configured using industry-accepted hardening standardsADR documenting choice of AMI, container base image, or OS configuration baseline, with reference to the standard applied (CIS Benchmark, NIST, etc.)ADR names the specific benchmark version and the deviations accepted with justification
12.3.2 ★Targeted risk analysis performed for each requirementADR for compensating controls or customised approaches includes the risk analysis that justified the deviationRisk analysis is quantified, not qualitative only; residual risk is stated
12.3.3 ★Cryptographic cipher suites reviewed at least annuallyADR documenting cipher suite decisions, including deprecated algorithm removalADR dated within 12 months; superseded ADRs visible in Git history
1.2.4Accurate network diagram maintainedADR documenting network architecture changes — new VPC, new subnet, new peering connection — with diagram update referencedArchitecture diagram version referenced in ADR matches current AWS Config resource inventory
8.6.2Passwords/passphrases for service accounts not embedded in filesADR documenting decision to use Secrets Manager or Parameter Store for credential managementADR predates deployment; no hardcoded credentials found in repository history after ADR date

★ New or materially changed in PCI DSS 4.0.1

What a QSA Should Look for in an ADR Corpus

When an entity presents ADRs as compliance evidence, the QSA's review should cover five dimensions:

01
Coverage — are all security-relevant decisions documented?
The ADR corpus should cover changes to network topology, authentication mechanisms, cryptographic choices, data storage decisions, and third-party integrations affecting the CDE. Gaps — decisions that clearly happened but have no ADR — are themselves a finding. The QSA can identify gaps by comparing the ADR index against the CloudTrail change history for the assessment period.
02
Contemporaneity — were ADRs written before or after implementation?
ADR timestamp should precede or match the infrastructure change. An ADR committed after the corresponding AWS Config configuration change indicates a retrospective documentation exercise — which does not satisfy the intent of the requirement. Verify using git log on the ADR file and CloudTrail CreateOrModifyResource timestamps.
03
Approval — is there evidence of authorised review?
Pull request approval history shows who reviewed the ADR. The QSA should verify that reviewers are authorised approvers — i.e., they appear in the access control list for the repository and have the role required to approve production changes. A self-approved ADR (author = approver) does not satisfy separation of duties requirements.
04
Security content — does the ADR address security implications?
Many engineering ADRs are written without security considerations. For PCI DSS purposes, an ADR that documents a change to a CDE component must include: the security implications of the decision, the alternatives considered and their security trade-offs, and any residual risks accepted. An ADR that records only "we chose X because it was faster" has no compliance value.
05
Linkage — is the ADR traceable to the deployed change?
The ADR should reference the change ticket, the deployment pipeline run, or the Infrastructure-as-Code commit that implemented the decision. Without this linkage, the ADR and the implementation cannot be confirmed as describing the same change — a gap that QSAs must flag.

Writing ADRs That Survive QSA Review

The following template structure produces ADRs that satisfy PCI DSS evidence requirements without requiring additional documentation. Teams that use this structure for every CDE-affecting decision generate a compliance evidence corpus as a side-effect of their normal engineering process.

ADR template for PCI DSS compliance evidence:

# ADR-[number]: [Decision title]

## Status
[Proposed | Accepted | Superseded by ADR-xxx | Deprecated]

## Date
[ISO 8601 date — must match or precede implementation PR date]

## Context
[What is the problem being solved? What is the current state of the
CDE component affected? Include the PCI DSS requirement that this
decision affects, if applicable.]

## Decision
[What was decided? Be specific — include service names, configuration
values, and the authorising individual or group.]

## Alternatives considered
[What else was evaluated? For each alternative, include why it was
rejected — particularly any security reason for rejection.]

## Security implications
[What are the security consequences of this decision? Does it
introduce new attack surface? Does it remove a compensating control?
What is the residual risk?]

## PCI DSS requirements addressed
[List sub-requirements this decision contributes evidence toward.
Example: Req 3.4.1 (encryption at rest), Req 3.5.1 (key management)]

## Implementation reference
[Change ticket: JIRA-1234]
[Infrastructure PR: github.com/org/repo/pull/567]
[CloudTrail event: arn:aws:cloudtrail:... EventId: abc-123]

## Approved by
[Name, role — must be an authorised approver per change management policy]

ADRs and Customised Approach (PCI DSS 4.0.1)

PCI DSS 4.0.1 introduced the Customised Approach as an alternative to the Defined Approach for entities with mature security programmes. A Customised Approach requires the entity to define the control objective, demonstrate how their control meets it, and document the risk analysis that supports the deviation. ADRs are the natural home for this documentation:

  • The ADR documents the control objective (the PCI DSS requirement it replaces or supplements).
  • The ADR documents the alternative control chosen, the service or mechanism implementing it, and the configuration.
  • The ADR documents the risk analysis — likelihood, impact, residual risk — that the QSA uses to validate the customised approach under Req 12.3.2.
  • The Git history shows when the risk analysis was performed — satisfying the contemporaneous documentation requirement.

Common failure mode: Entities adopt the Customised Approach without maintaining ADRs for the customised controls. When QSAs ask for the risk analysis required by Req 12.3.2, the entity cannot produce a contemporaneous document — only a retrospective narrative. Retrospective risk analyses do not satisfy the requirement.

Interactive assessment

Apply this in your assessment

This assessment maps directly to the controls in this article. Use it to generate gap evidence, cardholder data flow diagrams, or scoping documentation for a PCI DSS assessment — free with a Sync Your Cloud account.

Architecture Change Impact Analyser
Analyse the PCI DSS impact of an architecture change and generate a structured ADR with pre-filled security implications, affected sub-requirements, and risk analysis — ready for QSA review.