AWS EDP Compliance Requirements: What the Contract Actually Obligates

EDP negotiations focus on the headline: effective discount, term length, ramp profile. The compliance language inside the same contract receives a fraction of the attention and shapes the actual operating posture of your AWS estate for the entire term. Across $2.4B+ in AWS spend reviewed and 500+ engagements, the compliance terms are the section we most consistently see signed without redline — and the section that most consistently creates problems eighteen months later.

This article walks through the compliance obligations embedded in a standard EDP, the addenda buyers should request, and the audit-and-reporting language that determines who controls visibility into your AWS estate.

What the standard EDP obligates

A typical AWS EDP contract includes obligations across five categories:

1. Usage reporting

The buyer agrees to use AWS-provided billing and usage data as the source of truth for commitment consumption. This is operationally trivial but has implications: any independently-calculated number you maintain must reconcile to AWS source data, or the AWS number wins by default at true-up time.

2. Acceptable use

The standard AWS Acceptable Use Policy applies. The EDP does not change the underlying policy but explicitly incorporates it by reference. Worth re-reading at signing — the AUP has evolved meaningfully over the past several years, particularly around AI and machine learning workloads.

3. Compliance certifications

AWS makes specific certifications available (SOC 1, SOC 2, ISO 27001, PCI DSS, HIPAA BAA, FedRAMP). EDP buyers have access to these by default, but invoking them often requires specific paperwork — for example, the HIPAA BAA must be separately countersigned to govern PHI workloads.

4. Audit rights

The standard contract grants AWS broad audit rights against the buyer's use of AWS services. It grants the buyer narrower rights to audit AWS's compliance with its own certifications, typically through reliance on third-party attestation reports rather than direct audit. This asymmetry is largely non-negotiable but worth understanding.

5. Data residency and transfer

Default EDP language covers data residency through the choice of region but does not constrain AWS's ability to transfer metadata, billing data, or operational telemetry across regions. Buyers with strict cross-border restrictions (particularly in EU, financial services, and certain APAC jurisdictions) need to negotiate explicit addenda.

Industry-specific addenda

Several industries require specific EDP addenda or modifications:

Healthcare (HIPAA)

HIPAA BAA covering PHI workloads. AWS provides a standard BAA template; some healthcare buyers negotiate modifications. The BAA applies only to AWS accounts that the buyer designates as HIPAA-eligible; non-designated accounts cannot host PHI.

Financial services

Various jurisdictional addenda. EU buyers typically negotiate DORA-compliant terms (Digital Operational Resilience Act) covering operational resilience, third-party risk, and incident reporting. US buyers may negotiate FFIEC-aligned terms. UK buyers often negotiate FCA-aligned terms for outsourcing arrangements.

Public sector

FedRAMP, ITAR, and (for non-US public sector) jurisdictional sovereignty addenda. AWS GovCloud and AWS Secret Region operate under separate contracts but interact with EDP commitment math in jurisdiction-specific ways.

EU residency

The standard EU addendum covering GDPR-aligned data processing terms. Required for EU customer data. The 2023 AWS European Sovereign Cloud announcement created additional addendum options for buyers requiring stronger sovereignty guarantees.

Cross-border transfer

Standard Contractual Clauses (SCCs) for transfer of personal data from EU to US. AWS provides a standard SCC implementation; some buyers negotiate modifications.

Reporting cadence obligations

The standard EDP requires:

• Monthly invoicing and usage reporting.
• Quarterly commitment-tracking report (the formal AWS view of your burn-rate vs commitment).
• Annual true-up reconciliation at term anniversaries.
• Term-end reconciliation at contract expiry.

Buyers can additionally request:

• Monthly executive business review (EBR) covering commitment status, service adoption, and program updates.
• Custom usage attribution reports (e.g., by cost-allocation tag, by service category).
• Architectural review reports (Well-Architected Framework Reviews).
• Roadmap previews under NDA for upcoming AWS services and pricing changes.

None of these are automatic. They require explicit request, typically routed through the AWS account team.

The audit rights question

AWS retains broad rights to audit the buyer's use of AWS services for compliance with the Acceptable Use Policy and the commercial terms of the EDP. Buyers typically have narrower rights, reliant on AWS's published third-party attestation reports (SOC 1, SOC 2 Type II, ISO 27001, PCI DSS AOC, and others).

Three audit-related provisions worth negotiating:

1. Notice period for AWS audits. Standard language grants AWS short notice. Push for 30+ days notice for non-incident-related audits, with shorter notice acceptable for genuine security incidents.
2. Information sharing in response to buyer-side compliance investigations. When your regulators or auditors require AWS-side information, the standard language is often inadequate. Negotiate specific information-sharing obligations triggered by buyer regulatory inquiry.
3. Penetration testing rights. AWS publishes a standard pen-test policy. Buyers in security-sensitive industries often want broader rights. These are negotiable for enterprise-scale buyers but typically require specific use cases to justify.

Data residency provisions that matter

Region choice is one part of data residency. The other parts are less visible:

• Operational data. Telemetry that AWS collects about your account — CloudTrail metadata, Cost and Usage Report aggregation, account configuration data — may transit and persist outside your operating region. Negotiate explicit residency obligations if this matters to you.
• Support engagement data. When you open AWS Support cases, the data shared is processed by AWS Support globally by default. Premium Support tiers can offer regional restriction; this requires explicit configuration.
• AI/ML training data. Default Bedrock and SageMaker terms protect customer data from AWS-side model training, but the provisions have evolved and continue to evolve. Re-read at every renewal.
• Marketplace transactions. Marketplace ISV transactions involve data flows between the buyer, AWS, and the ISV. Default terms may not align with your residency requirements. Address explicitly when consolidating ISV spend through Marketplace.

Compliance obligations on the buyer side

The EDP also imposes obligations on the buyer:

• Maintain accurate account holder information.
• Use AWS services in compliance with applicable law.
• Not use AWS services in a manner that violates third-party rights.
• Cooperate with AWS investigations of acceptable use violations.
• For specific services (Bedrock, certain ML services), specific use restrictions (no high-risk applications without explicit AWS approval).

These are largely standard. The provision worth most attention is the Bedrock and ML use-restriction language, which has expanded significantly in recent contract templates and may constrain certain product use cases.

The checklist for your next EDP signing

Before signing or renewing an EDP, confirm each of these:

• Active HIPAA BAA covering all PHI-eligible accounts (if applicable).
• Jurisdictional addenda current for all operating geographies (GDPR/SCCs for EU, FCA for UK financial, DORA for EU financial, etc.).
• Audit-and-information-sharing language updated to current regulatory environment.
• Operational data residency obligations explicit (not just region choice).
• Acceptable Use Policy review — particularly the AI/ML provisions, which have evolved.
• Reporting cadence aligned with internal governance (quarterly EBRs requested if useful).
• Penetration testing rights aligned with security program needs.
• Bedrock and ML use restrictions reviewed against current and roadmap product use cases.
• Successor compliance: provisions covering what happens to compliance obligations if AWS-side service changes affect your posture mid-term.

What to avoid

Signing without legal review. Procurement-only EDP review misses compliance language that requires legal interpretation. Even sub-$5M EDPs benefit from legal review of the compliance addenda.

Treating compliance as boilerplate. AWS contracts evolve. Provisions that were standard three years ago may have changed materially. Re-read the current template at every renewal.

Assuming default coverage. Specific certifications (HIPAA BAA, FedRAMP, ISO addenda) require explicit invocation. Buyers regularly assume coverage they do not have.

Ignoring AI/ML provisions. The most rapidly evolving area of AWS contract language is around AI services. Buyers with significant Bedrock or SageMaker exposure should treat the AI/ML provisions as a focused negotiation area, not a boilerplate clause.

Putting it together

Compliance language inside an EDP is binding for the entire term. The hour you spend on focused redline at signing prevents the eighteen months of remediation that follow signing problematic terms.

For an independent compliance review of your current or proposed EDP, Contact Us.

For broader context, see our coverage of EDP negotiation, EDP multi-account strategy, and EDP private pricing.

Frequently asked questions.