ASD ISM 0661 Holding human users accountable for data transfers they perform
What it says
Human users transferring data to and from systems are held accountable for data transfers they perform.
Quoted as published. Everything else on this page is written by Control Stack.
What it means
In plain EnglishEvery person who moves data into or out of a system is identifiable and answerable for that transfer, so nobody can move data anonymously or deny having done so.
This control is about accountability, not about blocking transfers. When a person copies data onto a USB drive, uploads a file to a cloud service, emails a document out, or imports data into a system, the organisation must be able to say who did it, and that person must know they are answerable for it. In practice, accountability rests on three things working together. Users must act under individual, non-shared identities so a transfer can be tied to a real person. Transfers must be recorded in a way that shows who moved what, where and when. And users must have been told, and ideally have acknowledged, that they are responsible for the transfers they perform and for following the organisation's rules on them. Why it matters: data transfers are one of the most common ways information leaves an organisation, both by accident and by design. An insider can walk out with sensitive data, or a well-meaning staff member can move a file somewhere it should not go. If transfers are anonymous, or performed through shared accounts and generic import/export mechanisms, the organisation cannot investigate an incident, cannot correct behaviour, and cannot deter misuse. Knowing that a transfer will be attributed to you is itself a strong deterrent, and it gives the organisation the evidence it needs when something goes wrong. The statement covers both directions (transfers to systems and from systems) and applies to human users specifically, as distinct from automated system-to-system transfers.
Free. Save your status, tasks and notes.
Why it matters
Without accountability, data transfers become effectively anonymous. A data spill or theft cannot be traced to the person responsible, investigations stall, and disciplinary or legal action becomes impossible. Staff have little deterrent against careless or malicious transfers because they know nothing will be attributed to them. The organisation may also be unable to demonstrate to regulators, clients or an incident response team who handled the data, undermining trust and increasing the cost and duration of any breach response.
How to implement
System owners, with the identity team, configure every data transfer channel (removable media, email, web upload, file shares, managed file transfer, import/export tools) so it can only be used from an individually authenticated user account, and disable or restrict transfers from shared, generic and service accounts used by people.
The security team enables and centralises logging on each transfer channel so every transfer records the user identity, timestamp, data or file identifier, source and destination, and forwards these logs to a store the transferring user cannot modify or delete.
The security or governance team writes the data transfer procedure and acceptable use policy to state plainly that users are personally accountable for transfers they perform, and HR or the training team have every user acknowledge this at onboarding and at each refresher.
For transfer processes that use a register or approval workflow (for example bulk exports or media transfers), the process owner requires the performing user to be named on the record, and rejects entries that only name a team or a shared mailbox.
The security team schedules a periodic review of transfer logs and registers, follows up anomalies directly with the named user, and records the outcome so the accountability trail is exercised rather than just collected.
Keep it running
Day to day, this control lives in three places: identity, logging and people.
**Identity.** Transfers should only be possible while a user is authenticated under their own account. Shared, generic or kiosk accounts break attribution, so where they cannot be eliminated, transfers from them should be prohibited or routed through an individually authenticated step (for example a named user must approve or perform the export).
**Logging.** Transfer channels (removable media, email attachments, web uploads, file shares, managed file transfer tools, cloud sync clients, system import and export functions) should record the user identity, the time, the file or data set, the source and the destination. These records need to be retained long enough to support an investigation and protected from tampering by the user who performed the transfer.
**People.** Staff should be told, in policy and in induction and refresher training, that they are personally responsible for data transfers they perform, including transfers on behalf of others. Acceptable use agreements or transfer procedures that users sign are a practical way to make this explicit. Where a transfer process uses a register, form or approval workflow, the person performing the transfer should be named on it.
Reviews of transfer logs, and follow-up with the named user when something looks wrong, are what turn the record into actual accountability. Investigations of suspected inappropriate transfers should be handled through the organisation's normal HR and incident processes.
Evidence and audit
- Check 1 of 5What an auditor asks for
Ask for
Ask for the data transfer policy or procedure and the acceptable use policy that users sign.
Look at
Look for explicit wording that users are personally accountable for transfers they perform, both to and from systems, and for evidence that users have acknowledged it.
Good evidence
Good looks like clear accountability language, a signed or recorded acknowledgement for each current user, and refresh at induction or periodic training.
- Check 2 of 5What an auditor asks for
Ask for
Ask for a list of the mechanisms staff use to transfer data in and out of systems, and how each authenticates the user.
Look at
Check whether every channel requires an individual login, and whether any shared, generic or kiosk accounts can perform transfers.
Good evidence
Good looks like all channels tied to named accounts, with shared accounts either unable to transfer or forced through a named-user step.
- Check 3 of 5What an auditor asks for
Ask for
Ask for transfer logs from a sample of channels covering a recent period.
Look at
Confirm each entry records who performed the transfer, when, what data, and the source and destination, and that logs are stored where the user cannot alter them.
Good evidence
Good looks like complete, attributable entries retained centrally with integrity protection and a defined retention period.
- Check 4 of 5What an auditor asks for
Ask for
Ask for a transfer register, media register or export approval record where one is used.
Look at
Check that a specific person is named as having performed each transfer rather than a team, role or shared mailbox.
Good evidence
Good looks like every entry attributable to one individual, with unnamed or team-only entries rejected by the process.
- Check 5 of 5What an auditor asks for
Ask for
Ask for evidence of log or register reviews and any follow-up with users about questionable transfers.
Look at
Look at whether reviews happen on a schedule, whether anomalies are traced back to the named user, and how outcomes are recorded.
Good evidence
Good looks like regular reviews with documented follow-up to individuals, and cases escalated through incident or HR processes where warranted.
Mappings
Closest match in ISO/IEC 27001: A.5.14, Information transfer policies and procedures, which partially overlaps with this control.
ISO/IEC 27001: 5 mappings
This control partially overlaps A.5.14.
ISM-0661 requires users to be accountable for data transfers they perform to and from systems. Annex A 5.14 involves establishing information transfer rules, procedures, or agreements that cover transfer methods and channels. These overlap where transfer procedures such as approved methods and logging provide the basis for attributing transfers to individuals, thus supporting accountability. However, Annex A 5.14 mainly focuses on governing transfer mechanisms, whereas ISM-0661 is specifically about user accountability.
This control partially overlaps A.8.12.
ISM-0661 holds users accountable for data transfers they perform. Annex A 8.12 requires data leakage prevention (DLP) measures across systems, networks, and devices, including logging and alerts which overlap by attributing and monitoring transfers to reinforce accountability. However, Annex A 8.12 focuses on data leakage prevention, while ISM-0661 emphasises user accountability for transfers.
This control depends on A.5.10.
ISM-0661 requires user accountability for data transfers across systems. Annex A 5.10 requires documented acceptable use and handling rules for information and associated assets, defining the permitted transfer methods and user obligations when moving data. This supports ISM-0661 by clarifying expectations and enabling accountability through policy. Annex A 5.10 does not require attribution of transfers to specific users.
This control depends on A.6.4.
ISM-0661 requires that individuals who transfer data can be held answerable for those actions, presuming consequences for violations. ISO/IEC 27001:2022 Annex A 6.4 supports this by formalising a disciplinary process for information security violations, enabling enforcement when a user performs an unauthorised or improper data transfer.
This control depends on A.8.15.
ISM-0661 requires that human users who transfer data into or out of systems are identifiable and accountable for those specific transfer actions. ISO/IEC 27001:2022 Annex A 8.15 supports this by requiring logging of relevant activities and events so transfers can be attributed to a specific user and later reviewed. Annex A 8.15 is broader in that it covers all security-relevant events (not just data transfers), but without adequate logging, ISM-0661 accountability is difficult to evidence.
Mappings show how controls relate across frameworks. They do not imply full equivalence or certification.