Turn “data stays in region” into a data-flow inventory with named data types, processors, storage locations, transient processing locations, access paths and retention periods. Ask the vendor to bind its answers to the specific pilot configuration and model or analysis route. Then compare those answers with your source classification, contract and legal requirements before giving repository access. A region shown on the main database is not enough if prompts, logs, backups, support tools or exports follow another path.
The required boundary differs by company and data. Source code may include secrets, personal data in fixtures, customer identifiers or commercial material; a separately authored synthetic repository has a different risk profile from a live production repository. For personal data, have counsel assess the actual parties, their roles, applicable processing terms and any international-transfer question under the GDPR. This checklist supports that review; it does not decide legal compliance for a vendor.
Define the boundary before the vendor call
The privacy reviewer should write down the permitted geography and whether it applies to storage, processing, human access, and recovery copies. “EU” can mean one named cloud region, any EU region, or an approved cross-region set; those are different policies. Include identities and support data if your policy covers them. Define prohibited categories, such as live secrets or customer records, and the approved test repository.
Have the platform and security teams map exactly what the scanner receives. A repository integration may have access to more than the selected code path, and a diagnostic trace may include source fragments even if the final finding does not. Ask whether the pilot will use synthetic files, a narrowed repository grant or a controlled upload. Record the repository's owner and approval for the connection.
Use this register before authorizing access:
| Data or access path | Questions to ask | Evidence to retain |
|---|---|---|
| Repository grant and source snapshot | Which repos, scopes and revisions can be read? Where is source fetched, staged and analyzed? | Permission capture, data-flow diagram, storage configuration |
| Prompts, model input and output | Does any source or derived context reach another provider or region? Is there fallback routing? | Exact model/service, deployment mode, region policy, routing evidence |
| Logs, traces and support | Can requests or source excerpts be logged? Who can inspect them and from where? | Logging configuration, redaction policy, support-access procedure |
| Findings and exports | Do reports contain source, line excerpts, secrets or personal data? Where are they stored and sent? | Sample sanitized report, export destinations, access policy |
| Backups and deletion | What persists after the run? How long are backups kept? What does deletion actually remove? | Retention schedule, deletion procedure, backup location |
| Identity, email and billing | Do account names, user data, notifications or payment events use other processors? | Subprocessor list and service-specific location disclosures |
“Encrypted at rest” belongs in the control column, but it does not answer who can decrypt plaintext during analysis, what an operator can access, or where model processing occurs. Request the key holder, decryption path and support-access procedure. Do not treat deletion of a working copy as physical erasure of backups or provider-held records.
Trace the model route, not just the cloud region label
If a vendor uses a managed inference service, ask for the exact invocation mode, source region, possible processing destinations and fallback rules for the chosen model. Amazon Bedrock's model availability documentation distinguishes In-Region, geographic cross-Region and global cross-Region support. AWS's geographic cross-Region inference documentation explains that requests can be routed from a source Region to destination Regions within a geography. Those are AWS service capabilities, not claims about any particular security vendor. A vendor that promises one named region must show that its chosen route and operational configuration meet that narrower promise.
Logging deserves its own check. AWS documents optional Bedrock model invocation logging, including prompt and completion data when enabled. Whether a vendor enables logging, where it sends logs, and how it redacts them are configuration facts to verify. A general statement that “the model does not train on your data” does not answer logging, retention, support access or regional processing. Customer-configured invocation logging is also separate from provider-side retention: the current AWS geographic-routing guidance notes model-dependent abuse-detection storage in destination Regions. Check the exact model and service terms; disabling your own logging is not proof of zero provider retention.
Ask the vendor for configuration evidence appropriate to the service: selected region, model identifier or inference profile, allowed destination regions, logging destinations, and a description of what happens when the preferred model is unavailable. A refusal to run is a legitimate control when no permitted route exists; silent fallback to an unapproved destination is not.
Reconcile a dossier that contradicts the sales answer
Cedar Transit and every configuration record below are fictional. No AWS account was accessed and no model call was made. Cedar permits private-source acquisition, processing, source-bearing logs and recovery copies only in eu-west-1. Its separate human-access rule permits approved support personnel in the EEA. Findings may remain for 30 days; source-bearing working and diagnostic copies must be removed within 24 hours after the run. Those are Cedar's chosen requirements, not universal legal rules.
The buyer has approved only a public synthetic fixture for the initial demonstration. A private production repository remains disconnected. The vendor says “all customer data stays in the EU” and supplies dossier D1:
| Evidence ID | D1 record | What it establishes | What it does not establish |
|---|---|---|---|
| D1-01 | Source cache and findings configured in eu-west-1 |
Named storage locations for those two stores | Inference, logs, replicas or human access |
| D1-02 | Invocation configuration names a geographic profile; supplied destination list includes eu-west-1 and eu-central-1 |
The proposed route permits processing outside the required single Region | That every invocation did so, or that any private source has been transferred |
| D1-03 | Optional customer invocation logging disabled | That logging control is off in the captured configuration | Absence of application traces, provider retention or support copies |
| D1-04 | Application error log sample includes source-bearing prompt fragments; log destination is regional | These traces contain protected source and need the same boundary | That the 90-day log retention meets the 24-hour source-copy rule |
| D1-05 | Findings backup schedule says 35 days; replica location missing | Retention differs from the proposed 30-day findings limit | Where recovery copies live or when restored records expire |
| D1-06 | Support document says “global on-call access” | Current procedure does not establish the required personnel restriction | That unapproved access actually occurred |
| D1-07 | Contract draft refers to a subprocessor list and provider terms | The documents that need to be reconciled | That their actual model-specific retention and locations meet Cedar's policy |
There are known mismatches and unknowns, not one generic “pending security review.” D1-02's allowed destination set fails the single-Region route requirement. D1-04's source-bearing retention exceeds the stated limit. D1-05 shows a retention mismatch and leaves geography unknown. D1-06 leaves support access inadequately bounded. Good findings from the synthetic demo cannot offset any of them.
The buyer sends a targeted request:
For the exact proposed private-source configuration, provide the model/service identifier and invocation mode, allowed destinations and fallback behavior; the application and provider retention categories; redacted trace samples after source logging is removed or brought within policy; backup locations and restore/expiry behavior; and the support roles and controls enforcing the permitted access location. Bind these to a dated configuration revision. A replacement EU-wide diagram is insufficient for the
eu-west-1requirement.
A geographic profile need not imply a transfer outside the EEA. It still fails Cedar's stricter geography rule. Keep the commercial policy decision and counsel's transfer analysis distinct.
Decide on a configuration, then make changes expire that decision
Suppose dossier D2 arrives with a proposed, uninvoked regional configuration. It uses an identified in-Region model mode, has no cross-Region fallback, removes source from application diagnostics, supplies regional backup locations and reconciles the 30-day findings limit, and documents restricted support access. The provider's exact model-specific retention terms are still unanswered.
The decision remains bounded:
Continue only the approved public synthetic evaluation. D2 resolves the documented route, application-log and backup mismatches on paper. Private-source access remains unapproved until the selected provider retention and support controls are accepted by the accountable owners. A configuration export establishes intended settings; the subsequent authorized pilot must also retain evidence that it used that configuration. No private source has been processed in this exercise.
Do not treat one successful invocation as proof that fallback can never happen. Retain both the permitted-route configuration and evidence of the assessed invocation. Likewise, removing a log statement today does not erase yesterday's trace copies; the retention/deletion record must account for existing copies and restores.
Once the real buyer has accepted all required evidence, the authorization should name the repository, permitted analysis revisions or branches, configuration revision, model mode, permitted data categories and expiry/review triggers. Record the provider grant separately: a repository-level GitHub contents permission is not restricted to the chosen analysis branch or commit. Use a separate fixture repository or owner-prepared snapshot when the wider repository cannot be disclosed. Changing the model, invocation profile, diagnostic setting, support route or backup policy invalidates the corresponding evidence. A cheaper fallback introduced next month is a new data-handling decision, even if the database stays in the same Region.
The useful deliverable is a claim register with pass, fail or unknown per path, linked to artifacts and an owner. It should let a colleague answer why D1 failed, what D2 changed and why the remaining unknown still matters.
For GDPR-covered personal data, the European Data Protection Board's transfer guidance explains how to analyze whether a processing operation is an international transfer. Region alone does not answer every transfer question, and remote access or an onward disclosure needs fact-specific review. Have counsel assess the real data categories, parties, instructions and contract; do not infer a lawful transfer from a vendor's infrastructure slogan.
Reconcile changes before reusing the approval
Cedar's eventual acceptance should identify the configuration that satisfied its chosen boundary. A later pilot run using a different processing route, support arrangement or backup schedule is a changed proposal. Compare the changed item with the accepted record before treating the original decision as applicable. This is especially useful during an outage, when an operationally attractive fallback may violate the pilot's declared location rule.
Give that comparison an owner who can involve the relevant specialists. Platform can establish which route is configured and used; the data owner can determine whether the affected material is permitted; counsel can address any fact-specific legal question. No single screenshot answers all three. Keep the run identity and configuration evidence together so the team can distinguish an approved design from the route a particular job actually followed.
At closeout, reconcile each retained copy category with its own deadline. A successful working-directory cleanup does not close an unanswered log or backup question. Conversely, a documented retained backup with an accepted expiry should not be described as an unexplained failure if that exception was part of Cedar's decision. Record the actual result, remaining commitment and responsible owner. The useful outcome is a traceable handling decision, including its exceptions, rather than an undifferentiated “EU compliant” badge.
Leave the pilot with a usable answer
The output should be a signed data-flow register, not a generic “GDPR compliant” box. Attach the vendor diagram and configuration evidence, list every unresolved path, and state which repository and pilot mode are authorized. If a mandatory route cannot be shown, defer broader access and either use a synthetic fixture under an approved exception or evaluate a different deployment mode. Recheck after a model change, new subprocessor, support change or retention-policy update.
Give the security leader the exact open conditions for the final pilot decision memo. For the broader product evaluation, see the two-week scanner pilot guide.