Use of unencrypted portable storage media and devices
ISO/IEC 27018 Annex A.11.5 requires you to prohibit transporting PII on unencrypted portable storage media or devices, except where no reasonable alternative exists. To operationalize it, implement a default ban, enforce encryption technically, and run a strict exception process with compensating controls, approvals, and traceable evidence. 1
Key takeaways:
- Make “no unencrypted portable media for PII” the default rule, enforced by technical controls and process gates.
- If an exception is unavoidable, treat it as a high-risk transfer with documented “no reasonable alternative” justification and compensating controls.
- Keep audit-ready artifacts: policy, technical enforcement proof, exception records, training, and transfer logs.
This requirement targets a common breach path: PII copied onto portable devices and moved outside managed systems. ISO/IEC 27018 Annex A.11.5 sets a clear baseline: do not transport PII on unencrypted portable storage media or devices, unless you truly have no reasonable alternative. 1
For a CCO or GRC lead, the operational challenge is not writing the policy. The challenge is preventing “quiet exceptions” such as engineers exporting customer records to a USB drive to debug an incident, a third party field tech requesting a dataset for offline work, or a migration team moving files between environments outside approved tooling. Auditors will look for two things: (1) you can demonstrate prohibition in day-to-day operations (not just intent), and (2) your “no reasonable alternative” exceptions are rare, controlled, and provably mitigated.
This page gives you requirement-level guidance: scope, practical control design, an exception decision path, evidence to retain, and the exam questions you should be able to answer without scrambling. Where helpful, it also notes how teams often fail this control in practice and how to avoid those traps.
Regulatory text
Requirement (verbatim): “The use of unencrypted portable storage media and devices for transporting PII shall be prohibited unless there is no reasonable alternative.” 1
Operator meaning: You must establish a prohibition against moving PII on portable storage or portable devices if the PII is not encrypted. If a team claims there is “no reasonable alternative,” you must be able to show the rationale and the added safeguards that reduced the risk as far as practical. 1
Plain-English interpretation
- Default rule: If PII must be transported, it must not be on portable media unless it is encrypted.
- Exception rule: If someone insists unencrypted portable media is required, they must prove there is no reasonable alternative and you must apply compensating controls before any transfer happens.
- Practical audit bar: “Prohibited” implies more than a statement. You should expect to show technical restrictions, monitoring, and a workflow that makes violations difficult.
Who it applies to
Entity scope: Cloud service providers acting as PII processors under ISO/IEC 27018. 1
Operational scope (where this bites):
- Workforce endpoints: laptops/desktops that can write to USB storage, SD cards, external drives.
- Portable devices used for transport: phones/tablets used as storage, portable NAS devices, removable media adapters.
- Data movement workflows: incident response exports, customer support troubleshooting, bulk data extracts, migrations, offline processing for field work, and transfers to third parties.
Data scope: Any PII your organization processes in its role as a cloud PII processor, including customer datasets, logs containing PII, and derived exports that still identify a person.
What you actually need to do (step-by-step)
1) Define “portable storage media and devices” in your standard
Write a clear definition that includes common removable media and common portable device classes that can store data for transport. Keep it broad enough to cover new hardware types.
Output artifact: Portable Media Standard / Data Handling Standard section covering portable storage.
2) Establish the prohibition as a policy rule with clear scope
Your policy should state:
- PII may not be transported on unencrypted portable storage media/devices.
- Approved transport methods (examples: managed file transfer, encrypted channels to managed storage) and who can approve exceptions.
- Consequences for noncompliance (tie to disciplinary policy if you have one).
Operator tip: Don’t bury the rule inside a generic “encryption policy.” Auditors want to see the explicit prohibition tied to portable media and PII.
Output artifact: Policy text mapped to ISO/IEC 27018 Annex A.11.5. 1
3) Implement technical controls that make the prohibition real
Policy alone fails. Implement endpoint and system controls that reduce reliance on human behavior:
Common technical control patterns:
- Endpoint device control: block or restrict USB mass storage write access by default; allow only approved encrypted devices where feasible.
- Encryption enforcement: require full-disk encryption on endpoints; require hardware-encrypted removable drives or approved encrypted containers where removable media is permitted.
- DLP / content controls: detect and block copying files containing PII patterns to removable media (where your tooling supports it).
- Logging: record removable media insert events and file transfer events if possible; route to SIEM for alerting.
Output artifacts: Configuration baselines, MDM/endpoint control policies, screenshots/exports of settings, and change approval records.
4) Provide approved alternatives so “no reasonable alternative” stays rare
Teams reach for USB drives when approved routes are slow or unclear. Provide an easy, compliant default:
- Managed file transfer to controlled destinations
- Secure sharing to managed cloud storage with access controls
- Temporary access to a controlled sandbox environment instead of copying production PII
Output artifacts: Documented approved transfer methods, how-to guides, and service catalog entries.
5) Stand up an exception process for “no reasonable alternative”
Design this as a gated workflow. If the exception path is informal, it will turn into the default.
Minimum exception workflow fields to capture:
- Requestor, business owner, and data owner
- PII description and volume category (keep it qualitative if you don’t track volumes precisely)
- Purpose and timeframe
- Explanation of why approved alternatives are not reasonable
- Proposed compensating controls
- Approvers (security + privacy/compliance + data owner)
Compensating controls menu (pick what matches the scenario):
- Minimize data (only required fields/records)
- Short retention and verified secure deletion after use
- Chain-of-custody tracking for the media/device
- Restricted physical transport method (no “carry it around for a week”)
- Additional monitoring and post-transfer validation
Output artifacts: Exception register entries, approval records, and post-completion closure evidence.
Requirement alignment: The exception must justify “no reasonable alternative” and show controlled risk treatment. 1
6) Train the teams that actually move data
Aim training at roles with real transfer behavior: support, SRE/IR, data engineering, professional services, and any third party personnel operating under your control.
Training should cover:
- What counts as portable media/device
- Why unencrypted transport is prohibited
- Approved transfer methods
- How to request an exception (and that it is not a rubber stamp)
Output artifacts: Training content, attendance/completion logs, and targeted communications.
7) Monitor, test, and prove operating effectiveness
Build routine checks:
- Periodic reviews of endpoint control compliance
- Review exception register for patterns (repeat requesters, recurring justifications)
- Spot checks during incidents and migrations (high-risk times)
Output artifacts: Control test results, monitoring alerts (if triggered), and remediation tickets.
Required evidence and artifacts to retain
Keep evidence in a way that survives staff turnover and tool changes.
| Evidence type | What auditors look for | Examples |
|---|---|---|
| Policy/standard | Clear prohibition + exception condition | Data handling policy section referencing ISO/IEC 27018 Annex A.11.5 1 |
| Technical enforcement proof | Settings that prevent or control portable media use | Endpoint device control config export; MDM policy screenshots |
| Exception records | “No reasonable alternative” justification + approvals + closure | Exception tickets; approval emails in ticket; closure note confirming deletion |
| Approved alternatives | Users have a workable path | Runbooks; internal KB; transfer tool SOP |
| Training | Role-relevant awareness | Course module; completion report |
| Monitoring/testing | Ongoing verification | Quarterly test notes; SIEM alert rules; audit logs |
Common exam/audit questions and hangups
- “Show me how you prohibit unencrypted portable media transfers of PII.” Expect to demonstrate a control, not just a policy.
- “How do you define ‘no reasonable alternative’?” Auditors want a decision framework and examples of rejected requests.
- “How do you know this is working?” Bring testing results, monitoring outputs, and exception trend reviews.
- “What about third parties?” You need to cover contractors and other third parties who may handle your customers’ PII in your environment.
Frequent implementation mistakes (and fixes)
-
Mistake: Exceptions by email/Slack.
Fix: Require a ticketed workflow with mandatory fields and recorded approvals. -
Mistake: Blocking USB storage globally without providing alternatives.
Fix: Pair technical restrictions with a fast approved method for transfers, or teams will route around controls. -
Mistake: Treating “encrypted laptop” as satisfying the requirement.
Fix: The requirement is about transporting PII on portable media/devices unencrypted. Full-disk encryption helps, but you still need to address removable media and transport scenarios explicitly. 1 -
Mistake: No closure step.
Fix: Exceptions must end. Require attestation of secure deletion/return and close the ticket with evidence.
Enforcement context and risk implications
No public enforcement cases were provided for this specific ISO/IEC 27018 control in the source catalog, so you should treat it as a standards-driven requirement rather than building your rationale around named penalties.
Operationally, this control reduces the chance of uncontrolled PII loss events (lost drives, misplaced devices, informal handoffs). It also reduces investigative burden: if portable unencrypted transport is prohibited and technically constrained, incident scoping is tighter and easier to prove.
Practical 30/60/90-day execution plan
Immediate
- Publish the prohibition statement and scope definitions mapped to ISO/IEC 27018 Annex A.11.5. 1
- Identify where portable media is currently used (IR playbooks, migration runbooks, support workflows, third party field activities).
- Stand up an interim exception ticket type and require it for any portable-media transport involving PII.
Near-term
- Roll out endpoint controls to restrict removable storage writes by default, with a controlled allow-list process.
- Establish approved alternatives (managed transfer paths) and publish quick-start runbooks.
- Train high-risk teams and third party operators; require acknowledgment.
Ongoing
- Review exception trends and reduce root causes (missing tools, slow access provisioning, unclear guidance).
- Add targeted monitoring and periodic control tests, then track remediation to closure.
- Use a system of record (for example, Daydream) to keep the policy mapping, exception register, evidence, and control tests in one audit-ready workspace, so your ISO/IEC 27018 evidence does not fragment across tickets, wikis, and endpoint consoles.
Frequently Asked Questions
Does “portable storage media and devices” include phones and tablets?
If the device can store PII and be used to transport it outside controlled systems, treat it as in scope. Document your definition and enforce the prohibition consistently across removable media and portable devices used for transfer.
If a USB drive is encrypted, is it allowed?
The requirement prohibits unencrypted portable media for transporting PII, so properly encrypted portable media can be permitted under your standard. Keep controls around approval, logging, and secure handling so “encrypted” does not become “anything goes.” 1
What counts as “no reasonable alternative”?
Treat it as a high bar: approved transfer methods are infeasible due to a documented constraint (technical, contractual, or operational) and the business need is legitimate. Require the requestor to explain why each approved alternative will not work, and record your decision.
Do we need DLP to satisfy this requirement?
ISO/IEC 27018 Annex A.11.5 does not mandate DLP by name. You need a prohibition plus enforcement and an exception process that you can prove works; DLP is one option if it materially improves enforcement. 1
How should we handle incident response cases where engineers want to export PII to analyze offline?
Build an IR-approved alternative, such as a controlled analysis environment, and make it the default. If an exception is unavoidable, require minimized datasets, documented approvals, strict retention, and closure evidence.
How do we manage third party personnel who may copy data to portable media?
Flow the prohibition into third party onboarding, access rules, and acceptable use requirements. Enforce it through the same endpoint controls, and require exceptions to be requested and approved through your process.
Footnotes
Frequently Asked Questions
Does “portable storage media and devices” include phones and tablets?
If the device can store PII and be used to transport it outside controlled systems, treat it as in scope. Document your definition and enforce the prohibition consistently across removable media and portable devices used for transfer.
If a USB drive is encrypted, is it allowed?
The requirement prohibits **unencrypted** portable media for transporting PII, so properly encrypted portable media can be permitted under your standard. Keep controls around approval, logging, and secure handling so “encrypted” does not become “anything goes.” (Source: ISO/IEC 27018:2019 Information technology — Security techniques — Code of practice for protection of personally identifiable information (PII) in public clouds acting as PII processors)
What counts as “no reasonable alternative”?
Treat it as a high bar: approved transfer methods are infeasible due to a documented constraint (technical, contractual, or operational) and the business need is legitimate. Require the requestor to explain why each approved alternative will not work, and record your decision.
Do we need DLP to satisfy this requirement?
ISO/IEC 27018 Annex A.11.5 does not mandate DLP by name. You need a prohibition plus enforcement and an exception process that you can prove works; DLP is one option if it materially improves enforcement. (Source: ISO/IEC 27018:2019 Information technology — Security techniques — Code of practice for protection of personally identifiable information (PII) in public clouds acting as PII processors)
How should we handle incident response cases where engineers want to export PII to analyze offline?
Build an IR-approved alternative, such as a controlled analysis environment, and make it the default. If an exception is unavoidable, require minimized datasets, documented approvals, strict retention, and closure evidence.
How do we manage third party personnel who may copy data to portable media?
Flow the prohibition into third party onboarding, access rules, and acceptable use requirements. Enforce it through the same endpoint controls, and require exceptions to be requested and approved through your process.
Authoritative Sources
Operationalize this requirement
Map requirement text to controls, owners, evidence, and review workflows inside Daydream.
See Daydream