Episode 30 — Right-size cloud and virtualization scope with evidence
With roles clear, map cardholder data flows to named cloud components and mark exactly where storage, processing, and transmission can occur. Draw the browser to gateway leg, the application to tokenization provider leg, the batch settlement leg, and the administrative plane that can see or steer any of these. Label service names, accounts or subscriptions, regions, resource groups, and the precise objects where data rests or moves—buckets, disks, queues, functions, pods, and interfaces. Add the identity the workload uses when it crosses a boundary, because scoping is as much about “who acts” as “where it sits.” Then collect corroborating artifacts: firewall policy exports, storage access policies, load balancer listeners, function triggers, V P N and private-link definitions, and data-processing agreements for external hops. The assessment move is not to trust pretty maps; it is to make maps testable by pairing every arrow with a control that governs it and a log that records it. If a line lacks a control and a log, it is not ready to narrow scope.
Enable provider-native logging, flow records, and configuration tracking with retention aligned to policy, because the best evidence is the kind the platform produces automatically. Turn on A P I audit logs at the organization, account, or subscription level and route them to immutable storage with lifecycle rules and access reviews. Capture V P C or V N E T flow records for the subnets that matter, not just the perimeter, and keep enough detail to reconstruct conversations at useful granularity. Enable configuration trackers that snapshot resource states and emit diffs when something changes, then feed those diffs into alerts and tickets so a human reads them before drift becomes design. Align retention with incident and legal needs—longer for control-plane records, focused but sufficient for data-plane flows—and prove the alignment with screenshots and retrieval tests. The assessment move is to pick a date and ask, “Show me what changed, who changed it, and what traffic flowed right after.”
Validate encryption at rest and in transit with keys stored and managed in controlled services, because “enabled” is not the same as “governed.” Prove that storage services, disks, databases, and backups encrypt at rest with provider K M S or hardware security module-backed keys; show that key policies restrict who can use, rotate, or export them; and attach rotation evidence that names the person or process and the date. For encryption in transit, export listener configs, certificate chains, and mutual-auth settings for service-to-service flows; then sample packet captures at trusted tap points to confirm the ciphers and protocols match policy. Where private links or service endpoints bypass the public internet, document the route and the controls that keep the connection narrow and monitored. In review, a good program can answer three questions quickly: which keys protect this data, who can exercise those keys, and how do you know the session on this path is encrypted today.
Test isolation with packet captures, policy simulations, and cross-account or cross-tenant checks that mirror how attackers actually move. Start with simulator tools to confirm that declared routes and rules would deny unwanted paths; follow with authenticated probes from realistic sources to prove the denial leaves a log line you can find later. For containers and serverless, use service-mesh or egress policies to ensure functions cannot call arbitrary hosts; then run canary calls to forbidden domains and show the block. Attempt cross-account role assumptions with incorrectly scoped trust and confirm they fail; try to reach management endpoints from non-management subnets and capture the refusal. If wireless or V P N feeds enter the cloud, test split-tunnel logic and verify that corporate laptops cannot bridge from public internet to private cloud without passing a gateway you control. The evidence bundle is simulations, captures, logs, and the names of observers who witnessed time and place.
Document scoping logic and attach evidence so another professional can reproduce your conclusions step by step. Write the logic like a recipe: which accounts are in scope and why, which are out and why, where the cardholder data can flow, and what proves the allowed and denied paths. For each claim, list the artifact class (policy export, rule set, capture, ticket, attestation), the retrieval path, and the date last sampled. Keep one annotated diagram that uses the same labels your cloud consoles use so a reader can click into reality without translation. Place the package where change managers and assessors can both reach it, and update it when topology, identity, or providers change. Good scope is not a one-time essay; it is a living bundle that tracks the environment’s shape and the evidence that supports its boundaries.
Close the loop with a simple cadence that keeps cloudy complexity from drifting into myth. Tie segmentation checks to quarterly reviews, but also gate them on change: new V P Ns, new peering, new managed services, new gateways, new regions, and new identity brokers should all trigger focused retests with attachments. Teach teams to add evidence collection to their definition of done—if a control changed, the screenshot and export live next to the ticket before closure. Review a small sample each month across accounts and resource types, and publish one page of metrics that track privileged identity count, stale role age, untagged resource rate, and time to revoke risky keys. Leaders learn to steer when the dials remain steady and legible. Assessors learn to trust when scope reads like a map that matches the ground.
Two practical cautions belong in every cloud scoping conversation because they cause a surprising share of problems. First, management tools that “see everything” often ride networks and roles that “reach everywhere,” and if their pathways are not fenced and logged, they become the bypass you were sure did not exist. Reduce their standing power, broker their sessions, and snapshot their changes. Second, service conveniences—metadata endpoints, instance profiles, default trust policies—turn helpful into hazardous when nobody narrows them. Audit for wildcards, external principals, and star-grants; replace them with short, specific statements and a habit of renewal. Your evidence is the diff: a before with broad reach, an after with tight scope, and a date that shows the fix is now the baseline.
Finally, keep third-party and cross-team lines from blurring. If a managed detection provider ingests your logs, capture the contract that lists which feeds, how often, and how long they retain. If a development platform abstracts infrastructure, insist on exports that show the real objects underneath—networks, roles, and storage—so scope can be verified at the layer that matters. If a business unit runs an autonomous account, bind it to organization policies that enforce logging, tagging, identity baselines, and V P N standards by construction rather than persuasion. Scope that depends on goodwill will fray; scope that depends on guardrails and tests will last. The P C I P lens always returns to the same question: can you prove this boundary and this control today, with artifacts a stranger can read.
Close with one concrete move you can complete now. Select a single cloud workload that touches payment functions—an application stack, a data pipeline, or a batch settlement job—and revalidate its scope end to end. Export the network rules that isolate it, the identity policies that govern it, the logs that observe it, and the keys that protect it; run one deny test that should fail and capture the block; run one allow test that should succeed and capture the encryption and the logs it leaves behind. Update the evidence pack with today’s artifacts, link the change tickets that adjusted anything you fixed, and add a one-page scoping note that a colleague could follow tomorrow. With that small, defensible package in hand, you will have practiced the real craft behind cloud scope: not slogans, not wishful diagrams, but boundaries you can show, controls you can test, and a story any assessor can replay without your help.
