Cryptography sounds like specialist territory, but what is asked of a supplier in practice is standard functionality that mainly needs switching on.
Why is an unencrypted laptop a data breach?
Because whoever finds or steals an unencrypted laptop can reach everything on it, credentials and customer data included. With disk encryption (BitLocker on Windows, FileVault on Mac) the same lost laptop is only an annoying expense.
The measure is: encryption on by default on every device that can leave the building, enforced centrally rather than arranged per machine, and checked now and then to confirm it is still active everywhere. That check is what a customer audit wants to see.
What does sending data encrypted mean concretely?
HTTPS on your website and portals, encrypted connections (TLS) for email and file transfer, and outdated protocols switched off. For most companies this is largely already the case; the pitfalls are in old exceptions, such as an FTP connection from years back or an internal portal still running on plain HTTP.
A supplier sending customer data unencrypted across the wire has little to explain on a questionnaire and a lot to fix; the other way round, this is one of the easiest boxes to have demonstrably in order.
Do backups have to be encrypted as well?
Yes. An unencrypted backup held by an outside party is a data breach on standby: all your company data, neatly bundled, on infrastructure you do not manage. Enable encryption on the backup storage and record where the keys are kept, because an encrypted backup whose key existed only in the head of an administrator who has left is worth nothing when you need to restore.
Does email with customer data have to be sent encrypted?
Between mail servers that now happens with TLS by default, and for most correspondence that is enough. It becomes a different story once you send sensitive data: medical records, personnel files, large files of customer data. There you are expected to use a secure exchange method rather than an attachment, with a link that expires and a recipient who identifies themselves.
The most common finding on this point, incidentally, is not technical but human: files going to the wrong address. A short instruction on what may and may not leave as an attachment belongs to this topic just as much as the protocol does. See training for staff.
Which algorithms and key lengths are good enough?
The law names no algorithms, because they age. What it says is that you follow the state of the art. In practice: TLS 1.2 as the floor and TLS 1.3 where you can, AES-256 for storage, and old protocols such as SSL, TLS 1.0 and 1.1 switched off.
You do not have to work this out yourself. The default settings of your operating system and your hosting party are usually fine here; the work is in finding the exceptions somebody once enabled by hand. An external scan of your domain shows that in a few minutes, and the outcome is immediately a piece of evidence for proving your measures work.
Do the same requirements apply to phones and USB sticks?
For phones and tablets they do, and that is usually already handled: modern devices encrypt their storage by default as soon as a passcode is set. So the measure is not the encryption itself but enforcing that passcode, plus the ability to wipe a lost device remotely.
Removable media are the harder case. A USB stick with customer data left in a taxi is exactly the scenario this measure exists for. The simplest line is: no company data on removable media, exchange goes through a secure environment. If your work makes that impossible, allow only encrypted media and write it down as a rule in the acceptable use policy; see training for staff.
How this topic connects to backups and continuity and the rest of the duty of care is set out in the ten measures.