The UK's designation of Microsoft, Google Cloud, AWS, and Oracle as Critical Third Parties (CTPs) under direct financial regulator supervision changes what your compliance team must document. Starting next week, when the Bank of England, Prudential Regulation Authority, and Financial Conduct Authority begin joint oversight, your institution's reliance on these providers becomes a regulatory examination point.
This template structures your audit request to cloud providers in a format that satisfies both your internal risk committee and the new supervisory expectations under the CTP framework.
Purpose of the Template
This audit request template documents your institution's due diligence when relying on a designated cloud provider for services that touch your Cardholder Data Environment (CDE), payment processing infrastructure, or systems subject to operational resilience requirements under PCI DSS 4.0 or the UK's financial resilience framework.
Use it to:
- Request evidence of operational resilience controls from your cloud provider
- Document concentration risk assessment for your board and regulators
- Establish baseline expectations before the CTP regime creates new disclosure requirements
- Support PCI DSS Requirement 12.8.2 (service provider due diligence) and Requirement 12.9.1 (written agreements acknowledging responsibilities)
The template assumes your cloud provider hosts components in scope for payment processing, fraud detection systems, or customer-facing applications that handle authentication or transaction data.
Prerequisites
Before sending this request:
Map your CDE dependencies. Identify which cloud-hosted services process, store, or transmit cardholder data, or sit on the same network segment as systems that do.
Review your existing service agreements. Your Master Services Agreement likely contains audit rights language. This template exercises those rights; it doesn't replace contract negotiation.
Confirm your provider's CTP designation status. The UK designated Amazon Web Services EMEA SARL, Microsoft Ireland Operations Limited, Google Cloud EMEA Limited, and Oracle Corporation UK Limited. If your contract is with a different legal entity or region, clarify reporting lines.
Assign internal ownership. This request will generate documentation that your Qualified Security Assessor (QSA) will review during your next PCI DSS assessment and that your operational resilience officer must maintain under the UK framework.
The Template
Subject: Audit Request, Operational Resilience and CDE Controls Under UK CTP Framework
[Cloud Provider Name]
[Provider Contact/Account Team]
Dear [Provider],
As a financial institution subject to oversight by the Bank of England, Prudential Regulation Authority, and Financial Conduct Authority, we are conducting due diligence on critical technology services following your designation as a Critical Third Party under the UK's financial regulation framework.
Our use of [specific services: e.g., "AWS compute instances hosting our fraud detection engine and payment gateway API"] places these services within the scope of our operational resilience obligations and PCI DSS Requirement 12.8 (service provider management).
We request the following documentation and evidence to support our risk assessment and regulatory obligations:
**1. Operational Resilience Architecture**
- Incident response procedures and escalation paths for service disruptions affecting financial services customers
- Recovery Time Objectives (RTO) and Recovery Point Objectives (RPO) for services we consume
- Geographic redundancy and failover architecture for [specific regions/availability zones we use]
- Evidence of resilience testing conducted in the past 12 months, including scenarios simulating multi-customer impact events
**2. Concentration Risk and Dependency Mapping**
- Identification of shared infrastructure components (network, storage, hypervisor layers) that serve multiple financial institutions
- Third-party and fourth-party dependencies (upstream providers, connectivity vendors, hardware suppliers) that could create single points of failure
- Contractual and technical measures in place to prevent cascading failures across customers
**3. PCI DSS Compliance Evidence**
- Current PCI DSS Attestation of Compliance (AOC) and Report on Compliance (ROC) or Self-Assessment Questionnaire (SAQ)
- Responsibility matrix showing which PCI DSS requirements you satisfy and which remain our responsibility
- Segmentation controls and network architecture diagrams showing isolation between customer environments
- Cryptographic key management procedures, including [Key Encryption Key](/glossary/key-encryption-key) (KEK) and [Data Encryption Key](/glossary/data-encryption-key) (DEK) lifecycle controls meeting [FIPS 140-3](/glossary/fips-140-3) where applicable
**4. Regulatory Coordination and Transparency**
- Procedures for notifying financial institution customers of regulatory examinations, audit findings, or enforcement actions under the CTP framework
- Process for responding to information requests from the Bank of England, PRA, or FCA that concern our use of your services
- Advance notice protocols for material changes to architecture, security controls, or operational procedures that could affect our compliance posture
**5. Incident Notification and Root Cause Analysis**
- Commitment to notify us within [specify timeframe, typically 24-72 hours] of incidents that affect availability, integrity, or confidentiality of our data or services
- Sample incident report format showing root cause analysis depth and corrective action tracking
- Evidence of lessons-learned processes following past incidents
**Delivery Timeline:**
Please provide the requested documentation within 30 days. If any items require additional time or involve proprietary information subject to confidentiality restrictions, contact us to discuss alternative evidence or attestation formats.
**Ongoing Cadence:**
We expect to refresh this assessment annually and following any material change to our use of your services or your operational architecture.
This request supports our obligations under PCI DSS Requirement 12.8.2 and the UK operational resilience framework. We appreciate your cooperation in maintaining the resilience of critical financial services.
Regards,
[Your Name]
[Title]
[Institution Name]
Customizing the Template
Scope the request to your actual usage. If you only use object storage for encrypted backups, you don't need detailed payment gateway architecture. If you run real-time fraud detection models in their infrastructure, you need RTO/RPO commitments and incident response SLAs.
Adjust the timeline based on contract leverage. Tier-one financial institutions with enterprise agreements can reasonably request 30-day turnaround. Smaller institutions may need to negotiate or accept standardized responses.
Add PCI DSS requirement references specific to your environment. If you use their infrastructure for MFA (Requirement 8.4.2) or logging (Requirement 10.2), cite those requirements explicitly in Section 3.
Request formats your QSA will accept. If your QSA requires specific evidence formats (network diagrams in Visio, responsibility matrices in spreadsheet form), specify that upfront.
Clarify data residency if you operate across jurisdictions. If you have customers in multiple regions or process cross-border payments, request confirmation of where your data resides and which legal entities provide service in each region.
Validation Steps
After receiving responses:
Cross-check against your service agreement. The provider's stated responsibilities must align with what your contract says. Gaps indicate either contract ambiguity or misunderstanding that your legal team must resolve.
Compare PCI DSS responsibility matrices. Your QSA will hold you accountable for every requirement not explicitly satisfied by the provider. If the matrix shows you're responsible for network segmentation but you lack visibility into their network architecture, you have a compliance gap.
Test incident notification. Ask your account team to walk through a scenario: "If an outage affects our payment processing service at 2 a.m. on a Saturday, who gets notified and how quickly?" If they can't answer with names and SLAs, escalate.
Map their upstream dependencies to your concentration risk register. If they rely on a single connectivity provider or hardware vendor that also serves your other critical systems, you've identified concentration risk your board must understand.
Share relevant sections with your operational resilience officer. The UK framework requires institutions to identify and manage dependencies on critical third parties. This audit response becomes evidence that you've discharged that obligation.
The CTP designation doesn't create new technical requirements for cloud providers overnight, but it does create new transparency expectations. This template forces the documentation conversation before regulators ask why you don't have it.
