Data Carriage Across Borders

Data carriage across borders encompasses the preparation, transport, and restoration of digital information when personnel physically cross international boundaries with devices or storage media. Border authorities in many jurisdictions hold legal powers to inspect, copy, and retain electronic devices without the procedural protections that apply to premises searches or communications interception. These powers create specific risks for organisations handling sensitive programme data, protection information, or material that could endanger staff, partners, or beneficiaries if disclosed.

The procedures in this page address planned border crossings where staff have advance notice and can prepare accordingly. Emergency evacuations and hostile seizure scenarios require different approaches covered in the Data Evacuation and System Handover Under Duress playbooks respectively.

Prerequisites

Before beginning device preparation for border crossing, confirm the following conditions are met:

The risk assessment determines which preparation level applies. Three factors drive the assessment: the sensitivity of data normally present on devices, the inspection likelihood at planned border crossings, and the consequences if data were accessed by border authorities or subsequently leaked.

Data Classification for Travel

Travel classification categorises data by its risk profile during border crossing, distinct from general organisational data classification. Data that presents acceptable risk in normal operations may present unacceptable risk during border inspection where the organisation loses control over access, copying, and retention.

Travel classification assigns each data type to one of four categories:

Category A: Prohibited from travel devices. This category includes protection and safeguarding case data, beneficiary identification information linked to sensitive programme participation, staff security incident reports, investigation materials, data that could endanger individuals if disclosed to authorities in transit or destination countries, and any information subject to legal professional privilege. Category A data must not be present on travel devices under any circumstances. If the traveller requires access to Category A data at the destination, that data must be accessed via secure remote connection after arrival, never transported on devices.

Category B: Remove before crossing, restore after. Donor reports containing programme location details, partnership agreements with local organisations in sensitive contexts, operational security assessments, financial data including bank details, and authentication credentials beyond those required for device access fall into Category B. This data is removed from devices before crossing and restored from cloud backup after safe arrival.

Category C: Acceptable with encryption. General programme documentation without sensitive location data, published reports, training materials, and standard business correspondence present acceptable risk if devices are properly encrypted. Category C data may remain on devices during crossing.

Category D: No restrictions. Publicly available information, marketing materials, and data with no confidentiality requirements requires no special handling.

The data inventory process identifies what data exists on each travel device and assigns travel classifications. Run the inventory at minimum 72 hours before departure to allow time for data migration and secure deletion.

Device Preparation Procedure

Device preparation creates a travel-ready state where devices carry only Category C and D data, with full-disk encryption verified and verified restoration paths established for removed data.

1. Create complete device backup to organisational cloud storage

   Before modifying device contents, create a full backup that enables complete restoration if the device is lost, damaged, or seized.

   For Windows devices using OneDrive:

   # Verify OneDrive sync status
   Get-Process OneDrive -ErrorAction SilentlyContinue | Select-Object Id, ProcessName

   # Force sync of all known folders
   Start-Process "odopen://sync"

   # Verify sync completion in OneDrive settings
   # Settings > Sync and backup > Manage backup

For macOS devices:

   # Check iCloud Drive sync status
   brctl status

   # For organisational cloud (example: rclone to S3-compatible storage)
   rclone sync ~/Documents remote:backup/device-$(hostname)/Documents --progress
   rclone sync ~/Desktop remote:backup/device-$(hostname)/Desktop --progress

Verify backup completion by checking file counts and modification dates match between device and cloud storage. Record backup timestamp and location.

2. Identify and inventory data by travel classification

   Scan the device for files requiring classification. Automated scanning identifies common sensitive data patterns; manual review addresses organisation-specific content.

   # Find files modified in last 90 days (likely active use)
   find ~ -type f -mtime -90 -size +0 2>/dev/null | head -500

   # Find common sensitive file types
   find ~ -type f \( -name "*.xlsx" -o -name "*.docx" -o -name "*.pdf" \
     -o -name "*.csv" -o -name "*.db" -o -name "*.sqlite" \) -mtime -90

   # Check browser download folders
   ls -la ~/Downloads/
   ls -la ~/Desktop/

Review each identified file against travel classification criteria. Document files in Category A and B requiring removal.

3. Verify full-disk encryption status

   Confirm encryption is active and the encryption key is not stored on the device in recoverable form.

   For Windows BitLocker:

   # Check BitLocker status
   manage-bde -status C:

   # Expected output includes:
   # Conversion Status: Fully Encrypted
   # Percentage Encrypted: 100%
   # Encryption Method: XTS-AES 256

For macOS FileVault:

   # Check FileVault status
   fdesetup status

   # Expected output: FileVault is On.

   # Verify recovery key is escrowed (not on device)
   sudo fdesetup validaterecovery

For Linux LUKS:

   # Check LUKS encryption
   sudo cryptsetup status $(mount | grep ' / ' | cut -d' ' -f1)

   # Verify encryption algorithm
   sudo cryptsetup luksDump /dev/sda3 | grep cipher

If encryption is not enabled, enable it before proceeding. Do not travel with unencrypted devices containing any organisational data.

4. Remove Category A and B data from device

   Delete identified sensitive files using secure deletion methods that prevent recovery.

   For solid-state drives (SSDs), secure deletion relies on encryption rather than overwriting due to wear-levelling. The approach is: delete files, then clear free space.

   # Delete identified sensitive files
   rm -rf ~/Documents/ProjectX/
   rm -rf ~/Documents/CaseData/

   # Clear deleted file metadata on macOS
   rm -rf ~/.Trash/*

   # For additional assurance, use secure empty trash
   # System Settings > Privacy & Security > Advanced > "Empty Trash securely"

For Windows:

   # Delete sensitive directories
   Remove-Item -Recurse -Force "C:\Users\$env:USERNAME\Documents\Sensitive\"

   # Clear recycle bin
   Clear-RecycleBin -Force

   # Run cipher to overwrite deleted file space
   cipher /w:C:\Users\$env:USERNAME\Documents

After deletion, verify files are not present in cloud sync folders awaiting synchronisation, which would restore them.

5. Clear application caches and temporary files

   Applications retain data in caches that survive file deletion. Clear these caches to remove residual sensitive information.

   Browser cache clearing (Chrome example):

   # macOS Chrome cache locations
   rm -rf ~/Library/Caches/Google/Chrome/
   rm -rf ~/Library/Application\ Support/Google/Chrome/Default/Cache/
   rm -rf ~/Library/Application\ Support/Google/Chrome/Default/Service\ Worker/

For Windows:

   # Clear Chrome cache
   Remove-Item -Recurse -Force "$env:LOCALAPPDATA\Google\Chrome\User Data\Default\Cache"
   Remove-Item -Recurse -Force "$env:LOCALAPPDATA\Google\Chrome\User Data\Default\Code Cache"

   # Clear temporary files
   Remove-Item -Recurse -Force $env:TEMP\*

Clear application-specific caches for any software that accessed sensitive data: email clients, document editors, database tools, and remote access applications.

6. Sign out of sensitive accounts and remove cached credentials

   Sign out of accounts that should not be accessible during border inspection. Remove saved passwords from browser password managers and credential stores.

   Sign out of:

   • Email accounts (especially if email contains Category A/B content)
   • Cloud storage applications (OneDrive, Dropbox, Google Drive)
   • Password managers
   • VPN clients
   • Organisational applications with SSO

   # Remove macOS keychain entries for specific services (example)
   security delete-generic-password -s "organisation-vpn" login.keychain

   # Clear SSH keys if not needed during travel
   mv ~/.ssh ~/.ssh.backup.$(date +%Y%m%d)

Retain only credentials required for device login and restoration after arrival.

7. Synchronise remaining data to cloud and verify

   Ensure all Category C data remaining on the device exists in cloud backup, providing a restoration source if the device is seized.

   # Final sync verification
   rclone check ~/Documents remote:backup/device-$(hostname)/Documents

   # Expected: no differences found

Record the final sync timestamp. This becomes the restoration point if needed.

8. Document device state before departure

   Create a record of device preparation for post-travel verification and potential incident response.

   Record:

   • Device serial numbers and model identifiers
   • Operating system version
   • Encryption status and method
   • Categories of data remaining
   • Cloud backup location and timestamp
   • Hash of key system files (optional, for tamper detection)

   # Generate system state record
   system_profiler SPHardwareDataType > ~/travel-prep-$(date +%Y%m%d).txt
   fdesetup status >> ~/travel-prep-$(date +%Y%m%d).txt
   shasum -a 256 /System/Library/CoreServices/SystemVersion.plist >> ~/travel-prep-$(date +%Y%m%d).txt

Store this record separately from the travel device, either in cloud storage or with a colleague.

The following diagram illustrates the data flow during preparation and restoration:

+-----------------------------------------------------------+
|              PRE-DEPARTURE (48+ hours)                    |
+-----------------------------------------------------------+
|                                                           |
|  +------------------+     +------------------+            |
|  |  Travel Device   |     |  Cloud Storage   |            |
|  |                  |     |                  |            |
|  |  Category A -----+---->|  Full Backup     |            |
|  |  Category B -----+---->|  (encrypted)     |            |
|  |  Category C      |     |                  |            |
|  |  Category D      |     +------------------+            |
|  +--------+---------+                                     |
|           |                                               |
|           | Delete A, B                                   |
|           v                                               |
|  +------------------+                                     |
|  |  Travel Device   |                                     |
|  |  (travel-ready)  |                                     |
|  |                  |                                     |
|  |  Category C only |                                     |
|  |  Category D only |                                     |
|  +--------+---------+                                     |
|           |                                               |
+-----------------------------------------------------------+
            |
            | BORDER CROSSING
            v
+-----------------------------------------------------------+
|            POST-ARRIVAL (secure location)                 |
+-----------------------------------------------------------+
|                                                           |
|  +------------------+     +------------------+            |
|  |  Travel Device   |     |  Cloud Storage   |            |
|  |                  |<----+                  |            |
|  |  Category C      |     |  Full Backup     |            |
|  |  Category D      |     |  (encrypted)     |            |
|  |  + Restored B    |<----+                  |            |
|  |                  |     +------------------+            |
|  +------------------+                                     |
|                                                           |
|  Category A: Access via secure remote connection only     |
|                                                           |
+-----------------------------------------------------------+

Border Inspection Procedures

Border authorities exercise inspection powers differently across jurisdictions, but staff should prepare for the most intrusive reasonable scenario: device powered on, unlocked, and contents reviewed. The procedures below address inspection scenarios while protecting both data and staff safety.

Compliant Disclosure

When border officials request device access, comply with lawful requests while implementing protective measures:

1. Remain calm and cooperative

   Border inspection is a legal process. Confrontational behaviour increases scrutiny and risk. Cooperation does not require volunteering information beyond what is requested.

2. Power on and unlock the device when requested

   Provide the device password or biometric unlock when lawfully requested. Refusing lawful requests can result in device seizure, denial of entry, detention, or criminal charges depending on jurisdiction.

   The device contains only Category C and D data. Inspection reveals nothing sensitive because sensitive data was removed during preparation.

3. Do not volunteer access to cloud accounts

   Officials may request cloud account access. In most jurisdictions, you can truthfully state that you have signed out of cloud accounts and do not have credentials available on this device. Store cloud credentials in a password manager that is not installed on travel devices.

   If directly ordered to provide cloud credentials under threat of detention or other consequence, assess the risk to personal safety against data sensitivity. Personal safety takes priority. Inform IT support as soon as safely possible if cloud credentials are disclosed under duress.

4. Note inspection details for incident reporting

   After inspection, record:

   • Date, time, and location
   • Duration of inspection
   • What officials accessed or requested
   • Whether device left your sight
   • Whether you observed any connection of external devices
   • Names or badge numbers if visible
   • Receipt if device was retained

   Report the inspection to IT support within 24 hours. Even routine inspections should be logged for pattern analysis.

Device Seizure

If border officials retain your device:

1. Request documentation of seizure

   Ask for a receipt listing seized items with serial numbers. Note official names, agency, and stated reason for seizure if provided.

2. Do not provide passwords for seized devices

   Once a device is seized, you lose visibility into how passwords would be used. Many jurisdictions do not require password disclosure for seized devices. State that you need to consult with your organisation’s legal counsel before providing passwords for retained devices.

   If threatened with consequences for non-disclosure, request to speak with legal counsel. Assess personal safety risk. If safety requires disclosure, provide the password and immediately report to IT support.

3. Report seizure immediately

   Contact IT support to report device seizure. IT support will:

   • Revoke device certificates and access tokens
   • Change credentials the device may have cached
   • Assess data exposure risk based on device preparation state
   • Advise on next steps for obtaining a replacement device

4. Assume device compromise

   Treat any seized device as compromised even if later returned. Devices returned after seizure may contain monitoring software or hardware modifications. Do not use returned devices; submit them to IT for forensic examination and secure disposal.

Coerced Access Scenarios

Coerced access occurs when officials compel access through threats, detention, or physical intimidation beyond routine inspection. Staff safety takes absolute priority over data protection in coerced access scenarios.

If you experience coercion:

1. Comply with demands to ensure personal safety
2. Do not resist physically
3. Provide requested access including cloud credentials if necessary for safety
4. Report the incident at the first safe opportunity

IT support will treat reported coerced access as a security incident, revoking credentials and assessing exposure. Staff who disclose information under duress face no organisational consequences.

Data Restoration After Crossing

Restore data only after reaching a secure location with verified network connectivity. Do not restore data while still in transit or in locations where device security cannot be assured.

1. Verify arrival at secure location

   Confirm you are in a location with:

   • Physical security (private office, hotel room with secured door)
   • Network connectivity for cloud access
   • Time to complete restoration without interruption

   Do not restore data in airport lounges, cafes, or other public spaces.

2. Connect to secure network

   Use trusted network connectivity for restoration. Priority order:

   • Organisational VPN over any connection
   • Known secure WiFi with WPA3/WPA2
   • Mobile hotspot from organisational device
   • Hotel wired ethernet (generally preferable to hotel WiFi)

   Avoid public WiFi without VPN for restoration activities.

3. Authenticate to cloud services and verify account integrity

   Sign into cloud accounts and check for signs of unauthorised access:

   Review:
   - Recent sign-in activity for unfamiliar locations or times
   - Connected applications or OAuth grants
   - Recovery options (email, phone) unchanged
   - Active sessions list

If any anomalies appear, report to IT support before proceeding with restoration.

4. Restore Category B data from cloud backup

   Download or sync Category B data back to the device:

   # Restore from rclone backup
   rclone sync remote:backup/device-$(hostname)/Documents ~/Documents --progress

   # Verify file counts and sizes match backup
   rclone check remote:backup/device-$(hostname)/Documents ~/Documents

For OneDrive/SharePoint, re-enable sync for previously excluded folders through the OneDrive client.

5. Restore application configurations and credentials

   Sign back into applications signed out during preparation:

   • Email clients
   • VPN clients
   • Password managers
   • Cloud storage sync applications

   For password managers, verify the vault contents match expected state before using stored credentials.

6. Verify device integrity

   Compare current system state to pre-departure record:

   # Check system file hashes
   shasum -a 256 /System/Library/CoreServices/SystemVersion.plist

   # Compare with pre-departure record
   diff ~/travel-prep-20240115.txt <(system_profiler SPHardwareDataType; fdesetup status; shasum -a 256 /System/Library/CoreServices/SystemVersion.plist)

If system files differ unexpectedly, report to IT support for investigation before using the device for sensitive work.

7. Report travel completion

   Notify IT support of safe arrival and successful restoration. Report any incidents during travel, including routine inspections without issues.

The restoration sequence follows this flow:

+----------------+     +----------------+     +----------------+
|                |     |                |     |                |
|  Arrive at     +---->+  Connect to    +---->+  Verify cloud  |
|  secure        |     |  secure        |     |  account       |
|  location      |     |  network       |     |  integrity     |
|                |     |                |     |                |
+----------------+     +----------------+     +-------+--------+
                                                      |
                                                      | No anomalies
                                                      v
+----------------+     +----------------+     +-------+--------+
|                |     |                |     |                |
|  Report        |<----+  Restore       |<----+  Restore       |
|  completion    |     |  credentials   |     |  Category B    |
|                |     |  and apps      |     |  data          |
|                |     |                |     |                |
+----------------+     +----------------+     +----------------+
        |
        | If anomalies found at any step
        v
+----------------+
|                |
|  Report to     |
|  IT support    |
|  immediately   |
|                |
+----------------+

Country-Specific Considerations

Border inspection powers and practices vary significantly by jurisdiction. The following table summarises key considerations for common travel destinations and transit points. This information changes frequently; verify current conditions before travel.

For high-risk crossings, consider travelling with a dedicated travel device containing no organisational data. Configure the device before departure, use it exclusively during travel, and access organisational systems only via secure remote connection from the destination.

Verification

Confirm successful completion of border crossing procedures through the following checks:

Pre-departure verification:

• Full device backup completed and verified within 72 hours of departure
• Category A and B data removed from all travel devices
• Full-disk encryption enabled and verified
• Application caches cleared
• Sensitive account credentials removed
• Travel preparation record created and stored separately

Post-arrival verification:

• No unexplained account access during travel period
• Category B data restored successfully
• Application functionality confirmed
• Device integrity verification passed
• Travel completion reported to IT support

Troubleshooting

Documentation Requirements

Maintain records for each border crossing for security monitoring and incident response:

Pre-travel record:

• Traveller name and travel dates
• Devices carried (serial numbers, models)
• Data categories present on each device
• Backup location and timestamp
• Preparation completion confirmation

Post-travel record:

• Any inspection events (even uneventful)
• Duration and nature of any inspection
• Officials or agencies involved
• Device seizure or retention (with documentation received)
• Restoration completion confirmation
• Any anomalies observed

Retain records for 24 months minimum. Records support security incident investigation, pattern analysis across organisational travel, and insurance or legal claims if devices are seized or damaged.

See also

• Data Protection at Borders
• Device Security in Hostile Environments
• Data Evacuation
• Device Loss or Theft
• Operational Security