Safeguarding Case Management Security
Safeguarding case management security encompasses the technical controls, architectural patterns, and operational mechanisms that protect sensitive case data from unauthorised access, modification, or disclosure. Case management systems in safeguarding contexts handle information about vulnerable individuals, allegations of abuse, investigation findings, and protection interventions. The security architecture for these systems differs from general enterprise security because the consequences of a breach extend beyond organisational harm to direct risk of physical harm to survivors, witnesses, and staff.
The security model for safeguarding case management operates on the principle that access to case data must be constrained to the minimum necessary for each role, that every access must be recorded and attributable, and that data must remain protected even when systems operate in disconnected or hostile environments. These requirements demand purpose-built controls rather than reliance on general-purpose security configurations.
- Case
- A structured record documenting a safeguarding concern, including the individuals involved, the nature of the concern, actions taken, and outcomes. Cases progress through defined stages from intake through closure.
- Case owner
- The staff member with primary responsibility for a case, holding elevated access rights to all case data and the authority to grant access to others involved in the case.
- Case participant
- Any individual with a defined role in a case, including caseworkers, supervisors, specialists, and external service providers. Each participant receives access rights specific to their role.
- Data segregation
- The architectural separation of case data such that access to one case does not confer access to other cases, and access to one data type within a case does not confer access to other data types.
- Audit trail
- A tamper-evident chronological record of all access to and modifications of case data, capturing the identity of the accessor, the action performed, the timestamp, and the context of access.
- Field encryption
- Encryption applied to individual data fields within a record, allowing the system to store and transmit records while specific sensitive fields remain encrypted and accessible only to authorised roles.
Security Architecture
The security architecture for safeguarding case management systems implements defence in depth through layered controls at the network, application, data, and operational levels. Each layer provides independent protection such that compromise of one layer does not automatically compromise others.
+--------------------------------------------------------------------------+| SAFEGUARDING CASE MANAGEMENT SECURITY |+--------------------------------------------------------------------------+| || +--------------------------------------------------------------------+ || | NETWORK LAYER | || | | || | +------------------+ +------------------+ +------------------+ | || | | Network | | TLS 1.3 | | IP allowlisting | | || | | segmentation | | enforcement | | (where viable) | | || | +------------------+ +------------------+ +------------------+ | || +--------------------------------------------------------------------+ || | || v || +--------------------------------------------------------------------+ || | APPLICATION LAYER | || | | || | +------------------+ +------------------+ +------------------+ | || | | Authentication | | Session | | Request | | || | | (MFA required) | | management | | validation | | || | +------------------+ +------------------+ +------------------+ | || | | || | +------------------+ +------------------+ +------------------+ | || | | Role-based | | Case-level | | Field-level | | || | | access control | | permissions | | access control | | || | +------------------+ +------------------+ +------------------+ | || +--------------------------------------------------------------------+ || | || v || +--------------------------------------------------------------------+ || | DATA LAYER | || | | || | +------------------+ +------------------+ +------------------+ | || | | Encryption at | | Field-level | | Key management | | || | | rest (AES-256) | | encryption | | (per-case keys) | | || | +------------------+ +------------------+ +------------------+ | || | | || | +------------------+ +------------------+ | || | | Data segregation | | Backup | | || | | by case | | encryption | | || | +------------------+ +------------------+ | || +--------------------------------------------------------------------+ || | || v || +--------------------------------------------------------------------+ || | AUDIT LAYER | || | | || | +------------------+ +------------------+ +------------------+ | || | | Access logging | | Modification | | Tamper-evident | | || | | (all reads) | | tracking | | storage | | || | +------------------+ +------------------+ +------------------+ | || +--------------------------------------------------------------------+ || |+--------------------------------------------------------------------------+Figure 1: Layered security architecture for safeguarding case management
The network layer isolates case management systems from general network traffic. Safeguarding systems reside in dedicated network segments with firewall rules permitting only authenticated connections from known endpoints. TLS 1.3 encryption protects all data in transit, with certificate pinning where client applications support it.
The application layer enforces authentication before any case data access, requires multi-factor authentication for all users, manages session lifecycles with aggressive timeouts, and validates all requests against the user’s current permissions. The access control subsystem within the application layer operates at three levels: role-based controls determine what functions a user can perform, case-level permissions determine which cases a user can access, and field-level controls determine which data elements within accessible cases the user can view or modify.
The data layer protects information through encryption at rest using AES-256, field-level encryption for the most sensitive data elements, and cryptographic key management that can isolate keys per case when required. Data segregation ensures that database queries cannot return data from cases the requesting user lacks permission to access.
The audit layer captures every access event and modification in tamper-evident logs. These logs store in append-only storage with cryptographic integrity verification, ensuring that attempts to modify audit records are detectable.
Access Control Models
Access control for safeguarding case data combines role-based access control at the system level with discretionary access control at the case level. This hybrid model recognises that while organisational roles determine general capabilities, case access decisions require case-by-case determination based on the specific circumstances of each situation.
Role-based access control assigns permissions to roles rather than individual users. A caseworker role grants the ability to create cases, view cases to which the user has been assigned, and modify case records within defined parameters. A supervisor role grants the ability to view all cases within a geographic or programmatic scope, approve certain actions, and reassign cases. A system administrator role grants the ability to configure the system but explicitly excludes the ability to view case content.
+----------------------------------------------------------------------+| ROLE HIERARCHY AND PERMISSIONS |+----------------------------------------------------------------------+| || +-------------------+ || | System | Permissions: || | Administrator | - Configure system settings || | | - Manage user accounts || +-------------------+ - View audit logs || | - NO case data access || | || v || +-------------------+ || | Programme | Permissions: || | Manager | - View aggregate statistics || | | - Access anonymised reports || +-------------------+ - NO individual case access || | || v || +-------------------+ || | Safeguarding | Permissions: || | Lead | - View all cases in scope || | | - Approve sensitive actions || +-------------------+ - Reassign cases || | - Override access restrictions || | || v || +-------------------+ || | Supervisor | Permissions: || | | - View team cases || +-------------------+ - Approve case actions || | - Conduct case reviews || | || v || +-------------------+ || | Caseworker | Permissions: || | | - Create new cases || +-------------------+ - View/edit assigned cases || | - Request specialist input || | || v || +-------------------+ || | External | Permissions: || | Specialist | - View specific cases (time-limited) || | | - Add specialist notes || +-------------------+ - NO edit of core case data || |+----------------------------------------------------------------------+Figure 2: Role hierarchy showing inherited and restricted permissions
The role hierarchy implements permission inheritance with explicit restrictions. Higher roles inherit lower-role permissions unless explicitly excluded. The system administrator role breaks this pattern by possessing system management permissions while being explicitly denied case data access. This separation ensures that technical staff who maintain the system cannot access sensitive case content.
Case-level access control determines which specific cases a user can access. When a case is created, the system assigns the creating user as the initial case owner. The case owner can then grant access to other users by adding them as case participants with specified roles. Each case maintains its own access control list independent of other cases.
+-------------------------------------------------------------------------+| CASE-LEVEL ACCESS CONTROL |+-------------------------------------------------------------------------+| || Case: SAF-2024-0847 || Status: Active || Classification: High sensitivity || || +-------------------------------------------------------------------+ || | ACCESS CONTROL LIST | || +-------------------------------------------------------------------+ || | | || | Owner: | || | +--------------------+ | || | | Maria Santos | Full access, can grant access | || | | (Caseworker) | Can transfer ownership | || | +--------------------+ | || | | || | Participants: | || | +--------------------+--------------------+-------------------+ | || | | User | Role in case | Access level | | || | +--------------------+--------------------+-------------------+ | || | | James Okonkwo | Supervisor | Review, approve | | || | | Dr. Amina Hassan | Medical specialist | View medical, | | || | | | | add notes | | || | | Legal Aid Org | External referral | Limited view, | | || | | | | expires 2024-12-01| | || | +--------------------+--------------------+-------------------+ | || | | || +-------------------------------------------------------------------+ || |+-------------------------------------------------------------------------+Figure 3: Case-level access control list with role-specific permissions
The intersection of role permissions and case access determines actual access rights. A user must have both the role-level permission to perform an action and case-level access to the specific case. A supervisor who has not been added to a case’s access list cannot view that case, even though their role grants case viewing capabilities. This dual-check mechanism prevents inadvertent access expansion.
Field-level access control restricts access to specific data elements within cases. Certain fields contain information so sensitive that not all case participants should view them. The survivor’s contact details, for example, might be visible only to the case owner and supervisor, while a medical specialist sees only medical history and treatment notes. Field-level access operates through classification tags applied to each field, with access granted based on the user’s role and specific grants for that case.
| Field category | Default access | Restricted access | Rationale |
|---|---|---|---|
| Case identifier | All participants | N/A | Required for case reference |
| Case status | All participants | N/A | Required for coordination |
| Case summary | All participants | N/A | Context for all roles |
| Survivor identity | Case owner, supervisor | Explicit grant only | Direct identification |
| Contact details | Case owner, supervisor | Explicit grant only | Location risk |
| Medical records | Medical specialists | Case owner review | Clinical sensitivity |
| Perpetrator details | Case owner, investigators | Explicit grant only | Safety risk if disclosed |
| Investigation notes | Investigators, supervisor | Explicit grant only | Legal sensitivity |
| Witness information | Investigators | Case owner notification | Witness protection |
Data Segregation Architecture
Data segregation ensures that access to one case does not provide access to others and that compromise of one data store does not expose all case data. The segregation architecture operates at multiple levels: logical segregation through access controls, physical segregation through data partitioning, and cryptographic segregation through per-case encryption.
Logical segregation enforces access boundaries through application-level controls. Every database query includes a filter for cases the requesting user can access. The application constructs queries to include only permitted case identifiers, preventing any query from returning data from inaccessible cases. This filter applies regardless of how the query originates, including administrative database access.
+------------------------------------------------------------------------+| DATA SEGREGATION ARCHITECTURE |+------------------------------------------------------------------------+| || Application Layer || | || v || +--------------------+ || | Access Control | || | Filter | || | (per-request) | || +--------------------+ || | || +---------------------+---------------------+ || | | | || v v v || +--------------+ +--------------+ +--------------+ || | Query: | | Query: | | Query: | || | Cases where | | Cases where | | Cases where | || | user=Maria | | user=James | | user=Admin | || | Result: | | Result: | | Result: | || | [0847, 0923] | | [0847, 0891, | | [empty set] | || | | | 0923, 0956] | | | || +--------------+ +--------------+ +--------------+ || || +------------------------------------------------------------------+ || | DATABASE LAYER | || +------------------------------------------------------------------+ || | | || | +------------+ +------------+ +------------+ +------------+ | || | | Partition | | Partition | | Partition | | Partition | | || | | Region A | | Region B | | Region C | | Region D | | || | | | | | | | | | | || | | Cases: | | Cases: | | Cases: | | Cases: | | || | | 0001-0500 | | 0501-1000 | | 1001-1500 | | 1501-2000 | | || | +------------+ +------------+ +------------+ +------------+ | || | | || +------------------------------------------------------------------+ || |+------------------------------------------------------------------------+Figure 4: Logical and physical data segregation across database partitions
Physical segregation partitions case data across separate database segments. Partitioning can follow geographic boundaries (cases from different regions in different partitions), programmatic boundaries (different safeguarding programmes in different partitions), or sensitivity boundaries (high-sensitivity cases isolated from standard cases). Physical partitioning limits the blast radius of a database compromise: an attacker who gains access to one partition cannot access cases in other partitions without separate compromise.
Cryptographic segregation encrypts case data with keys unique to each case or case group. When a user accesses a case, the system retrieves the case-specific decryption key from a key management service, provided the user has permission. Without the key, the encrypted case data remains unintelligible even if the attacker obtains the raw database contents.
A worked example illustrates the segregation mechanism. The database stores case SAF-2024-0847 with the following structure:
Case record (database): case_id: "SAF-2024-0847" partition: "region_east" encryption_key_id: "key_0847_v2"
encrypted_payload: "AES-256-GCM(...)"
access_control_list: [ { user_id: "maria.santos", role: "owner" }, { user_id: "james.okonkwo", role: "supervisor" }, { user_id: "amina.hassan", role: "specialist", fields: ["medical"] } ]When Maria Santos requests case 0847, the system performs these checks:
- The access control filter confirms maria.santos appears in the case’s access control list
- The system requests decryption key key_0847_v2 from the key management service, presenting Maria’s authentication token
- The key management service verifies Maria’s permission and returns the decryption key
- The application decrypts the case payload and applies field-level filtering based on Maria’s role
- Maria receives the decrypted case data with all fields visible (owner access)
When Dr. Amina Hassan requests the same case, step 4 differs: the application applies field-level filtering that reveals only medical-related fields, with other fields redacted or hidden.
When an administrator queries the database directly (bypassing the application), they see the case record but cannot decrypt the payload without the encryption key. The key management service denies key access to users without case-level permissions, regardless of their system role.
Encryption Requirements
Encryption for safeguarding case data operates at three levels: transport encryption protects data in transit, storage encryption protects data at rest, and field encryption protects individual sensitive elements.
Transport encryption requires TLS 1.3 for all connections to case management systems. TLS 1.2 remains acceptable where legacy system constraints prevent TLS 1.3, but TLS 1.1 and earlier versions must be disabled. Certificate validation must be strict, with no allowance for self-signed certificates in production environments. For mobile applications accessing case data, certificate pinning prevents man-in-the-middle attacks even if an attacker compromises a certificate authority.
Storage encryption protects the database, file storage, and backups. AES-256 encryption applies to all stored case data. The encryption implementation uses authenticated encryption modes (GCM or CCM) that provide both confidentiality and integrity verification. Key rotation occurs annually or upon suspected compromise, with the system maintaining the ability to decrypt historical data using archived keys.
Field encryption applies additional protection to the most sensitive data elements within case records. While storage encryption protects all data if the storage medium is compromised, field encryption protects specific elements even if an attacker gains application-level database access. Field encryption uses separate keys from storage encryption, with access to field encryption keys restricted to users with explicit permission for those fields.
| Encryption layer | Algorithm | Key length | Key rotation | Protects against |
|---|---|---|---|---|
| Transport | TLS 1.3 | 256-bit | Per-session | Network interception |
| Storage | AES-256-GCM | 256-bit | Annual | Storage media theft |
| Field | AES-256-GCM | 256-bit | Per-case | Application-level breach |
| Backup | AES-256-GCM | 256-bit | Per-backup | Backup media theft |
The key management architecture isolates encryption keys from encrypted data. Keys never store alongside the data they protect. A hardware security module (HSM) or cloud key management service holds master keys, with derived keys distributed to application servers in memory only. When an application server restarts, it must re-authenticate to the key management service to obtain keys.
For organisations without HSM infrastructure, cloud-based key management services (AWS KMS, Azure Key Vault, Google Cloud KMS) provide equivalent security with lower operational complexity. Self-hosted alternatives like HashiCorp Vault offer key management without cloud dependency, suitable for organisations with data sovereignty requirements that preclude cloud key storage.
Audit Trail Requirements
The audit trail for safeguarding case management captures every interaction with case data in sufficient detail to reconstruct who accessed what information, when, and in what context. The audit function serves multiple purposes: security monitoring to detect unauthorised access, accountability to demonstrate proper handling, legal evidence to support investigations, and quality assurance to identify training needs.
Audit event categories define what the system logs:
+------------------------------------------------------+| AUDIT EVENT TAXONOMY |+------------------------------------------------------+| || AUTHENTICATION EVENTS || +------------------------+ || | - Login success | || | - Login failure | || | - MFA challenge | || | - Session timeout | || | - Logout | || +------------------------+ || || ACCESS EVENTS || +------------------------+ || | - Case list view | || | - Case detail view | || | - Case search | || | - Document download | || | - Report generation | || | - Export request | || +------------------------+ || || MODIFICATION EVENTS || +------------------------+ || | - Case create | || | - Case update | || | - Case status change | || | - Document upload | || | - Note addition | || | - Case closure | || +------------------------+ || || PERMISSION EVENTS || +------------------------+ || | - Access grant | || | - Access revoke | || | - Role change | || | - Ownership transfer | || +------------------------+ || || ADMINISTRATIVE EVENTS || +------------------------+ || | - Configuration change | || | - User account change | || | - System parameter | || | - Audit log access | || +------------------------+ || |+------------------------------------------------------+Figure 5: Audit event taxonomy covering all case management interactions
Each audit record contains a standardised set of fields that enable reconstruction of the access context:
Audit record structure: event_id: "evt_20241115_143822_7f3a2b" timestamp: "2024-11-15T14:38:22.847Z" event_type: "case_view"
user: user_id: "maria.santos" session_id: "sess_8a4c2d" ip_address: "10.45.23.89" device_id: "dev_laptop_ms_01"
target: case_id: "SAF-2024-0847" fields_accessed: ["summary", "status", "notes", "actions"]
context: access_reason: "case_owner" query_origin: "case_detail_page" response_status: "success"Tamper evidence ensures that audit logs cannot be modified without detection. The system writes audit records to append-only storage where modification and deletion are technically prevented. Each audit record includes a cryptographic hash linking it to the previous record, creating a chain that reveals any tampering. Regular integrity verification compares stored hashes against computed values, alerting security staff to any discrepancy.
Retention requirements for safeguarding audit logs typically exceed standard IT logging retention. Where general system logs might retain for 90 days, safeguarding case audit logs retain for the lifetime of the case plus a defined period (often 7 years) to support potential future legal proceedings or inquiries. The retention period aligns with record retention requirements for safeguarding cases themselves.
Audit log access itself requires audit logging. Only designated security and compliance staff can view audit logs, and their access is itself logged. This meta-auditing prevents covert surveillance where someone with audit access might monitor case access patterns without accountability.
A worked example demonstrates audit trail usage. An investigation into potential unauthorised access to case SAF-2024-0847 examines the audit log:
Query: All access events for case SAF-2024-0847 between 2024-11-01 and 2024-11-15
Results: 2024-11-03 09:14:22 maria.santos case_view success case_owner 2024-11-05 11:23:45 maria.santos case_update success case_owner 2024-11-05 14:56:12 james.okonkwo case_view success supervisor 2024-11-08 16:34:09 maria.santos case_view success case_owner 2024-11-12 10:45:33 unknown_user case_view denied no_permission 2024-11-12 10:45:58 unknown_user case_view denied no_permission 2024-11-12 10:46:14 unknown_user case_view denied no_permission 2024-11-14 09:23:17 maria.santos case_update success case_owner
Analysis: Three denied access attempts from unknown_user on 2024-11-12 warrantinvestigation. Cross-reference with authentication logs to identify the userand determine whether this represents a security incident.Offline Case Management Security
Safeguarding work frequently occurs in environments without reliable network connectivity. Field staff conduct interviews in remote locations, travel between sites without consistent internet access, and operate in areas where network infrastructure is limited or unreliable. The case management system must support offline operation while maintaining security controls.
Offline data synchronisation provides field staff with case data when connectivity is unavailable. The system downloads a subset of case data to the local device, encrypted with device-specific keys derived from the user’s credentials. The offline dataset includes only cases assigned to that user, minimising exposure if the device is compromised.
+------------------------------------------------------------------------+| OFFLINE SYNCHRONISATION ARCHITECTURE |+------------------------------------------------------------------------+| || +----------------------------+ +----------------------------+ || | CENTRAL SERVER | | FIELD DEVICE | || +----------------------------+ +----------------------------+ || | | | | || | +----------------------+ | | +----------------------+ | || | | Full case database | | | | Local encrypted | | || | | (all cases) | | | | cache (user's cases) | | || | +----------------------+ | | +----------------------+ | || | | | | ^ | || | v | | | | || | +----------------------+ | | +----------------------+ | || | | Sync service |<--------->| Sync client | | || | | (filters by user) | | | | (encrypts locally) | | || | +----------------------+ | | +----------------------+ | || | | | | | | || | v | | v | || | +----------------------+ | | +----------------------+ | || | | Conflict resolution | | | | Offline audit log | | || | | (server wins/merge) | | | | (syncs when online) | | || | +----------------------+ | | +----------------------+ | || | | | | || +----------------------------+ +----------------------------+ || || Sync frequency: Every 15 minutes when connected || Offline validity: 72 hours maximum (configurable) || Conflict handling: Server authoritative, manual review for conflict || |+------------------------------------------------------------------------+Figure 6: Offline synchronisation with encrypted local cache
The offline validity period limits how long a device can operate without server contact. After 72 hours (configurable based on risk tolerance), the offline cache becomes inaccessible, requiring re-authentication with the central server. This limit contains the risk from stolen credentials: an attacker with a stolen device and credentials can access cached data only until the validity period expires.
Device encryption protects offline case data through full-disk encryption on all devices used for case management. The case management application adds a second encryption layer for its local cache, using keys derived from the user’s credentials. If the device is stolen while locked, the attacker faces two encryption barriers: the device’s full-disk encryption and the application’s cache encryption.
Offline audit logging continues recording access events when the device operates without connectivity. The offline audit log stores locally with the same tamper-evident structure as the central log. When connectivity resumes, the sync client uploads offline audit records to the central server, where they integrate into the main audit trail. The upload includes cryptographic proof that the records were created on the specific device at the recorded times.
Remote wipe capability allows administrators to erase case data from devices that are lost, stolen, or assigned to terminated staff. The wipe command queues on the server and executes when the device next connects. For devices that never reconnect, the offline validity period ensures that cached data becomes inaccessible regardless.
Security controls for offline operation necessarily accept trade-offs. A device with offline case access carries sensitive data outside the protected network perimeter. The controls described above mitigate but cannot eliminate this risk. Organisations must balance operational necessity (staff need case data in the field) against security exposure (data on field devices is more vulnerable than data on servers).
Implementation Considerations
Organisations with Limited IT Capacity
Small organisations and those without dedicated IT staff can implement safeguarding case management security through cloud-hosted platforms that provide security controls as built-in features. Platforms like Primero, CommCare, and dedicated safeguarding case management SaaS solutions implement the access control, audit, and encryption mechanisms described in this page without requiring local infrastructure.
The critical security decisions for these organisations focus on platform selection and configuration rather than implementation. When evaluating platforms, verify that the platform provides role-based access control with the ability to define custom roles matching your organisational structure, that it logs all case access with tamper-evident audit trails, that it encrypts data at rest and in transit using current standards, and that it supports offline operation with appropriate security controls.
Configuration priorities for limited-capacity organisations:
- Define roles that match actual job functions before creating user accounts
- Enable multi-factor authentication for all users before entering case data
- Configure case visibility rules to implement need-to-know principles
- Verify audit log retention meets regulatory requirements
- Test offline functionality and remote wipe capability before field deployment
Organisations with Established IT Functions
Organisations with dedicated IT staff have additional options including self-hosted platforms, custom development, and hybrid architectures. Self-hosting provides maximum control over data location and access, particularly relevant for organisations with data sovereignty requirements or operating in jurisdictions where cloud provider access creates risk.
Implementation considerations for self-hosted deployments:
Infrastructure security requires dedicated hosting for safeguarding systems, separate from general organisational infrastructure. The database server should reside in an isolated network segment with firewall rules permitting connections only from the application server. Administrative access to the database requires VPN or bastion host, never direct internet exposure.
Key management for self-hosted systems requires either HSM deployment or integration with a managed key service. HashiCorp Vault provides open-source key management suitable for organisations preferring not to depend on cloud key services. Key management infrastructure itself requires high-availability deployment to prevent case data becoming inaccessible during key service outages.
Audit infrastructure for self-hosted systems must address log storage security. Options include write-once storage (WORM), blockchain-based audit trails, or remote log shipping to a separate system where application administrators lack access. The audit system’s integrity depends on separation from the systems it monitors.
Backup architecture must maintain encryption for backup media while ensuring recoverability. Test restoration procedures quarterly, verifying that cases restore correctly with access controls intact. Backup media requires the same physical security controls as production systems.
High-Risk Operating Contexts
Organisations operating in hostile environments face additional threats including device seizure, coercive demands for access, and sophisticated surveillance. Security controls must account for scenarios where staff may be compelled to provide access under duress.
Duress codes provide a mechanism for staff to signal coercion. Entering a specific PIN variant (such as adding a digit to the normal PIN) triggers a duress response: the system appears to function normally while secretly alerting security staff and potentially displaying modified data that protects sensitive cases.
Case hiding allows designated high-risk cases to become invisible to users who have not been specifically granted access. Unlike normal access control where denied cases appear in search results marked as inaccessible, hidden cases do not appear at all. This prevents adversaries from learning that a case exists even if they cannot access its contents.
Plausible deniability configurations allow staff to maintain a visible case portfolio that does not include the most sensitive cases. If compelled to demonstrate system access, the staff member shows cases they genuinely manage, while hidden cases remain invisible. This approach requires careful ethical consideration and clear protocols about when staff should comply with access demands versus resist.
Travel protocols for staff carrying devices with case access define security measures for border crossings and movement through checkpoints. These protocols may specify removing case data from devices before travel, using dedicated travel devices with minimal data, or accessing case data only through cloud connections rather than local storage. See Data Protection at Borders for detailed guidance.