How this command is triggered — by the user, by Claude, or both
Slash command
/us-export:data-residencyThe summary Claude sees in its command listing — used to decide when to auto-load this command
# Data Residency Verification > **Engineering guidance only. Not legal advice.** ITAR and EAR residency postures vary by USML category, ECCN, deployment model, encryption posture, and CSP attestations. The defaults below are starting points, not compliance positions. The country lists here can lag the live BIS sanctions text; verify against the [BIS country guidance](https://www.bis.doc.gov/index.php/policy-guidance/country-guidance) and 22 CFR 120.54 (the ITAR encrypted-technical-data carve-out) before acting. Verifies data residency posture for ITAR (US-located by default) and EAR (BIS-...
Engineering guidance only. Not legal advice. ITAR and EAR residency postures vary by USML category, ECCN, deployment model, encryption posture, and CSP attestations. The defaults below are starting points, not compliance positions. The country lists here can lag the live BIS sanctions text; verify against the BIS country guidance and 22 CFR 120.54 (the ITAR encrypted-technical-data carve-out) before acting.
Verifies data residency posture for ITAR (US-located by default) and EAR (BIS-driven sanctions and licensing).
$1 - Framework (optional: itar, ear, both) - defaults to "both"$2 - Cloud provider (optional: aws, azure, gcp, all) - defaults to "all"ITAR-controlled technical data is stored in US-located systems by default. 22 CFR 120.54 carves out properly-encrypted technical data from the release definition, so deployment patterns where end-to-end-encrypted data is stored or transmitted abroad can be defensible. This is not a free pass: the encryption has to actually be end-to-end, the keys have to be controlled by US persons, and counsel needs to bless the posture in writing for your specific USML category and CSP. When in doubt, default to US-located regions.
US Government Regions:
us-gov-west-1 (Oregon) - US West (GovCloud)us-gov-east-1 (Virginia) - US East (GovCloud)Benefits:
Verification:
aws ec2 describe-regions --region us-gov-west-1
aws s3api list-buckets --region us-gov-west-1
Approved US Regions (with additional controls):
us-east-1 (Virginia)us-east-2 (Ohio)us-west-1 (California)us-west-2 (Oregon)Prohibited Regions:
US Government Regions:
usgovvirginia - US Gov Virginiausgoviowa - US Gov Iowa (DoD only)usgovtexas - US Gov Texasusgovarizona - US Gov Arizonausdodeast - US DoD Eastusdodcentral - US DoD CentralBenefits:
Verification:
az cloud list --query '[?name==`AzureUSGovernment`]'
az account list-locations --query '[?name==`usgovvirginia`]'
US Regions:
us-central1 (Iowa)us-east1 (South Carolina)us-east4 (Virginia)us-west1 (Oregon)us-west2 (Los Angeles)us-west3 (Salt Lake City)us-west4 (Las Vegas)Assured Workloads Configuration:
Verification:
gcloud compute regions list --filter='name:us-*'
gcloud assured list --location=us-central1
EAR doesn't impose a uniform "store data in US-only regions" rule, but it also isn't "any region worldwide minus four embargoed countries." 15 CFR 734.6 makes clear that BIS determines what licensing applies. The relevant access controls depend on:
The list below is a snapshot, not a substitute for the current BIS country guidance. Sanctions move quickly. Before deploying access controls, check the BIS country guidance page and the most recent Federal Register entries.
Comprehensive embargoes (broad export restrictions, 15 CFR 746):
Region-specific comprehensive sanctions (15 CFR 746.6):
Country-specific item-level controls (verify scope against current BIS text):
# Create WAF rule to block embargoed countries
aws wafv2 create-web-acl \
--name EAR-Embargo-Block \
--scope REGIONAL \
--default-action Allow={} \
--rules file://embargo-rule.json
# embargo-rule.json includes:
# GeoMatchStatement blocking: CU, IR, KP, SY
# Check CloudFront distribution restrictions
aws cloudfront get-distribution-config --id DISTRIBUTION_ID
# Configure geo-restriction
{
"GeoRestriction": {
"RestrictionType": "blacklist",
"Quantity": 5,
"Items": ["CU", "IR", "KP", "SY", "UA"]
}
}
# Create Front Door with geo-filtering
az network front-door create \
--name ear-compliance \
--resource-group myResourceGroup
# Add geo-filtering rules to block embargoed countries
# Create Cloud Armor security policy
gcloud compute security-policies create ear-embargo-block \
--description "Block embargoed countries for EAR compliance"
# Add rule to block countries
gcloud compute security-policies rules create 1000 \
--security-policy ear-embargo-block \
--expression "origin.region_code == 'CU' || origin.region_code == 'IR' || origin.region_code == 'KP' || origin.region_code == 'SY'" \
--action "deny-403"
| Framework | Requirement | Allowed Regions | Blocked Regions |
|---|---|---|---|
| ITAR | US-located by default; 22 CFR 120.54 encryption carve-out available | us-gov-, us-east-, us-west-* by default | Non-US regions unless encryption posture is documented and counsel-approved |
| EAR | BIS determines (15 CFR 734.6); ECCN-driven; sanctions per 15 CFR 746 | Depends on ECCN, license exceptions, and current sanctions | At minimum: comprehensive embargoes (CU, IR, KP, SY), Crimea/DNR/LNR (746.6), Russia and Belarus item controls (746.8). Verify against current BIS country guidance. |
Allowed: Multiple US regions for redundancy
Primary: us-gov-west-1
Backup: us-gov-east-1
Prohibited: Cross-border replication
us-east-1 → eu-west-1 ❌ PROHIBITED
us-gov-west-1 → us-gov-east-1 ✅ ALLOWED
Permitted regions depend on the ECCN, applicable license exceptions, and current 15 CFR 746 sanctions. Without those facts, "any region worldwide" is wrong. With those facts, common patterns:
Primary: us-east-1
DR: eu-west-1 ✅ Often OK for EAR99 / unrestricted ECCNs with denied-party screening; verify under your ECCN
DR: ap-southeast-1 ✅ Often OK for the same; check that no entity-list parties are in the access path
Always blocked (comprehensive embargoes plus region-specific sanctions):
Any region → Iran, Syria, Cuba, North Korea ❌
Any region → Crimea / DNR / LNR regions of Ukraine ❌
Item-controlled access → Russia, Belarus ❌ for items under 15 CFR 746.8
| Provider | ITAR Support | EAR Support | FIPS 140-2 | Notes |
|---|---|---|---|---|
| AWS GovCloud | ✅ Highly Recommended | ✅ Yes | Level 2+ | FedRAMP High, US persons |
| AWS Commercial | ⚠️ Limited (US regions) | ✅ Yes | Level 2+ | Requires additional controls |
| Azure Government | ✅ Highly Recommended | ✅ Yes | Level 2 | FedRAMP High |
| Azure Commercial | ⚠️ Limited (US regions) | ✅ Yes | Level 2 | Requires additional controls |
| GCP Assured Workloads | ✅ Recommended | ✅ Yes | Level 3 | With ITAR configuration |
| GCP Commercial | ⚠️ Limited (US regions) | ✅ Yes | Level 3 | Requires configuration |
AWS:
# S3 bucket locations
aws s3api list-buckets | jq -r '.Buckets[].Name' | while read bucket; do
location=$(aws s3api get-bucket-location --bucket "$bucket" --query 'LocationConstraint' --output text)
echo "$bucket: $location"
done
# RDS instances
aws rds describe-db-instances --query 'DBInstances[*].{Name:DBInstanceIdentifier,AZ:AvailabilityZone}'
# EC2 instances
aws ec2 describe-instances --query 'Reservations[*].Instances[*].{Id:InstanceId,AZ:Placement.AvailabilityZone}'
Azure:
# Resource locations
az resource list --query '[].{Name:name,Location:location}' --output table
# Storage account locations
az storage account list --query '[].{Name:name,Location:location}' --output table
GCP:
# Bucket locations
gcloud storage buckets list --format='table(name,location)'
# Compute instances
gcloud compute instances list --format='table(name,zone)'
# Cloud SQL instances
gcloud sql instances list --format='table(name,region)'
Use GovCloud/Government Regions
Disable Cross-Border Features
Verify US-Only Personnel
Implement Geo-Blocking
Monitor Access Logs
Screen Users by Geography
# Verify ITAR data residency (US-only)
/us-export:data-residency itar aws
# Verify EAR embargo screening
/us-export:data-residency ear all
# Comprehensive verification for both frameworks
/us-export:data-residency both all
# Azure-specific ITAR verification
/us-export:data-residency itar azure
⚠ ITAR technical data in a non-US region without the 22 CFR 120.54 encryption carve-out documented
s3://my-bucket (eu-west-1) holding plaintext or single-key-managed-by-CSP technical data ← high risk
⚠ Cross-border replication of plaintext technical data
us-east-1 → ap-southeast-1 with no end-to-end encryption layer ← high risk
⚠ CDN with non-US edge caching ITAR technical data
CloudFront with European edge locations caching ITAR-bearing payloads ← high risk
❌ Allowing access from embargoed countries
User login from Iran (IR) ← VIOLATION
❌ No geo-blocking configured
WAF rules allow all countries ← VIOLATION
❌ Denied party not screened
Entity List company granted access ← VIOLATION
8plugins reuse this command
First indexed Apr 26, 2026
Showing the 6 earliest of 8 plugins
npx claudepluginhub fianulabs/claude-grc-engineering --plugin us-export/data-residencyVerifies ITAR and EAR data residency requirements for specified frameworks and cloud providers, listing approved US regions and verification commands.
/data-residencyVerifies Protected B data residency in approved Canadian regions for AWS, Azure, or GCP (all by default). Supports check and remediate modes.
/data-residencyVerifies that data is stored in Australian regions (ap-southeast-2) for IRAP compliance, checking sovereignty requirements for PROTECTED data.
/data-residencyVerifies Japanese data residency requirements for ISMAP compliance, ensuring government data resides only in Tokyo or Osaka regions.