An Expiring Provider AOC, a New Region and Thin Evidence
Meridian Fitness runs 220 clubs plus e-commerce billing and is preparing an annual ROC. Its IaaS provider, CloudCo, has supplied an AOC that covers IaaS and lists which requirements are inherited, but it expires two months before Meridian's ROC is due to be issued and does not mention the managed database service Meridian uses for PAN. Meridian also outsources log monitoring to a managed SIEM provider that retains 90 days hot and 12 months in cold archive with 24-hour retrieval. The scope document was last updated ten months ago and does not include the eu-central-1 region launched four months ago, where PAN is stored in an RDS instance. Change management recorded 22 changes last quarter; the QSA sampled four. The most recent segmentation test was 14 months ago. Management states that “quarterly ASV scans are done by the provider” and would like the ROC to proceed on that basis.
1. How should the provider's AOC and its two-month expiry gap be treated in the assessment?
Read the worked answer
An AOC is evidence, not a transfer of responsibility. Meridian still owns every requirement CloudCo does not explicitly cover, and must show that inherited controls operate for Meridian's actual configuration.
- Coverage check first: does the AOC name the specific services and regions in use? An IaaS AOC that is silent on the managed database service does not cover that database. Requirements for that service remain Meridian's to evidence or to compensate for.
- Period check: the AOC must cover the assessment period. A two-month gap needs a bridge letter, a current SOC 2 Type II covering the gap, or other evidence of continuous operation. An expired certificate presented as current is the fastest way to lose credibility with a QSA and later with an acquirer.
- Responsibility mapping: obtain the provider's mapping of each PCI DSS requirement to provider or customer, and the written agreement that supports it (12.8/12.9 evidence).
- Independent verification: sample the inherited controls in Meridian's own tenancy - encryption enabled, public access blocked, admin MFA, logging delivered, patching cadence. Inheritance is a claim until it is observed.
- If the gap cannot be evidenced: the assessor cannot mark those requirements met on inheritance alone. Options are compensating evidence, a documented exception with a remediation plan, or bringing the control into Meridian's own assessment.
Proceeding “on that basis” without resolving the gap is not a defensible position.
2. What are the consequences of the unlisted eu-central-1 region, and what must be done before the ROC?
Read the worked answer
The new region stores PAN, so it is CDE regardless of whether it appears in the scope document. A ten-month-old document that omits a production region breaches 12.5.1 (a current inventory of in-scope components) and 12.5.2 (scope confirmed at least annually and reviewed after significant change).
Before the ROC:
- Inventory: add the region's accounts, VPCs, RDS instances, load balancers, external addresses and key aliases, with function and owner.
- Key management: confirm encryption is enabled and keys are regional with a key policy meeting 3.6/3.7, and that decrypt rights are not broader than in the primary region.
- Segmentation and testing: confirm segmentation controls exist there and are included in the segmentation test; extend the penetration test scope to the new region's external and internal surfaces (11.4.1–11.4.5).
- Scanning: add the new external IPs and hostnames to ASV scans and the internal instances to quarterly internal scanning.
- Logging: confirm logs ship to the SIEM, that retention applies, and that the region appears in monitoring rules.
- Change record: check whether a risk assessment and compliance review occurred at launch; if not, document the gap and its remediation.
The assessor will assess controls as they operate and sample the period since go-live. Four months without coverage may need remediation evidence or a documented exception. After the ROC, add a launch gate so no new region can go live without a compliance checklist.
3. Assess the sufficiency of evidence for log review, log retention, segmentation testing and change sampling.
Read the worked answer
- Log review (10.4.1): the requirement is review at least once daily, not merely retention. A monthly MSSP report proves the tool exists, not that anyone reviewed. Ask for review tickets, alert disposition timestamps with named reviewers, and escalation records. Sample days including weekends and holidays, because that is where daily review quietly stops.
- Log retention (10.3.3): twelve months retained, with the most recent three months immediately available for analysis. Ninety days hot plus Glacier with 24-hour retrieval does not meet “immediately available” - a day-long restore would cripple incident response. Extend searchable retention to at least 90 days and evidence a tested restore time.
- Segmentation testing (11.4.5): at 14 months it is out of date. Annual is the minimum; every six months applies where a service provider relies on segmentation. This is a straightforward finding - schedule and complete the test before the assessment date.
- Change sampling: four out of 22 is thin and the population may itself be unreliable if it came from a spreadsheet. The assessor should define the population from the pipeline, verify completeness, and sample across change types including emergency changes and their retrospective approvals.
The common thread is that existence evidence is not operating evidence; the ROC needs records showing the control ran, across the full population and the full period.