The Payment Portal Boundary That Excluded the Identity Provider
Meridian Payments runs a customer-facing payment portal on AWS. The authorization boundary diagram submitted to the assessor shows only three EC2 web servers and one RDS database. In reality, login is handled by an external identity provider, card data is tokenized by a third-party vault, logs flow to a SaaS SIEM, and a marketing microservice shares the same VPC and IAM roles as the portal. The assessor sampled 25 transactions and found that 7 passed through components outside the boundary. The system owner argues the identity provider and SIEM are inherited controls and should be excluded from scope. The compliance manager notes that the card-processor contract requires PCI DSS while the internal baseline is NIST SP 800-53 Moderate. Go-live is in 30 days, and the authorizing official must approve the boundary before the assessment can be completed.
1. Evaluate the claim that the identity provider and SIEM are inherited controls. How should the boundary be redrawn, and what evidence would you require?
Read the worked answer
“Inherited” is not a synonym for “outside scope.” A control can be inherited only when another organizational entity implements it, the system owner documents the inheritance in the SSP, and the provider supplies evidence that the control operates as required. The identity provider sits directly in the authentication path; if it is compromised or misconfigured, every portal account is exposed. It may remain outside the authorization boundary as an external service, but it cannot be excluded from assessment of IA controls without a customer responsibility matrix, a current independent attestation, and a contractual right to assess. The SIEM is a log consumer; its availability affects audit log protection and retention, and its own access controls matter because it holds sensitive logs.
The boundary should include the marketing microservice, because it shares the VPC and IAM roles with the portal. Shared roles create a privilege-escalation path that crosses the current boundary. I would redraw the boundary around the portal's accounts, VPC, data stores, and shared IAM trust relationships, and show the identity provider, tokenization vault, and SIEM as external dependencies with data-flow arrows.
Evidence required: updated SSP and boundary diagram; IAM role trust-policy review; card-data flow diagrams; SOC 2 or equivalent reports for each external provider; the card processor's PCI responsibility matrix; and a segmentation test showing whether the marketing service can reach payment data. The 7 out-of-boundary transactions are proof that the diagram is wrong, not merely incomplete.
2. What is the compliance impact of the 7 out-of-boundary transactions, and what would you require before the AO approves go-live in 30 days?
Read the worked answer
The 7-of-25 result is not a minor sampling anomaly; it shows the assessment population itself is misdefined. Controls cannot be tested over a path the SSP does not describe. For PCI DSS, any component that stores, processes, or transmits card data, or can affect its security, is in scope. The tokenization vault and the shared IAM roles are therefore likely in scope even if the vault is externally hosted. For the 800-53 Moderate baseline, the AO cannot conclude that access control, identification and authentication, system communications, and audit controls are effective when authentication and logging traverse unexamined services.
Before approval I would require:
- A corrected boundary and SSP, with a data-flow trace covering all 25 sampled paths and the 7 exceptions.
- A revised sampling plan drawn from the corrected population.
- Evidence of segmentation between the marketing microservice and payment workloads, or explicit inclusion of the microservice.
- Provider attestations and responsibility matrices for the identity provider, vault, and SIEM.
- Confirmation of PCI scope with the card processor.
If segmentation cannot be demonstrated, the AO should not authorize go-live as scoped. A 30-day delay is preferable to an authorization built on a known-incomplete boundary. If the business insists on launching, the defensible option is a constrained pilot with the marketing service disabled and the risky path removed, documented as a condition in the authorization decision. The AO should record the condition, the owner, and the date by which full scope will be assessed.