GDPR kind of mentions Encryption and Authentication for access to software and the stored data. It skirts around it a bit because best practice is not the same for every piece of software and there are lots for different software architectures out there that use different methodologies.
The actual wording of GDPR says personal data shall be:
Processed in a manner that ensures appropriate security of the personal data, including protection against unauthorised or unlawful processing and against accidental loss, destruction or damage, using appropriate technical or organisational measures
So the security needs to be appropriate to the situation, in such cases we rely on best practice, which is to use a process of encryption and authentication.
So what is the difference between encryption and authentication ?
Encryption is encoding data or information in a layer that can not be intercepted and read without a decryption key. The most obvious example of this is the SSL encryption websites use to protect sensitive information like bank accounts and logins. The connection between your computer and the server is encrypted using a public and private key, you have probably heard terms like 256 bit certificates that describes the actual size in bits of the encrypted certificate. While two computers are connected like this no-one can intercept and decrypt. Digicert say that It is estimated, that standard desktop computing power would take 4,294,967,296 x 1.5 million years to break a DigiCert 2048-bit SSL certificate. Which throws in to serious doubt the claims from the bloke I met in the pub who said he could hack any website given enough time. Passwords however are a different thing
Authentication is the process of making sure that the right person has access to the data stored on the computer. We all have passwords for lots of things, Facebook, bank accounts email.
Strong passwords are ones that use different character sets , upper case lower case , special characters and don’t form common words. Better passwords can be two part or use a checking system like Google authenticator or a text/email two step process.
With computer software and especially databases, your username and password also identifies who you are as a user and assigns you a role within that software. In a larger organisation some users have mores access to data and are able to do more things than others . Good software allows you to assign user roles and tailor those roles to the level of access requires.
GDPR defines some of these user roles in broad terms; again it’s what is appropriate and best practice for your organisation. Only those people in an organisation entitled to have access to the personal data stored should have a user level (or even a login) to see that data.
With software, it’s not just the user login that needs to be protected. With most software there is usually more than one way in apart from the user interface. Software has to be hosted on a server on the Internet or a PC in the building and there are levels of access and security for these. Software also typically runs an underlying database like SQL Server for instance that has its own interface and login which also needs to comply with security best practice. The worst cases of “stolen” personal data have been from people leaving their laptop on a bus (maybe with the password written on a post it note on the lid). GDPR even mentions physical security
None of this is rocket science, it’s just IT best practice. While GDPR calls on it and requires you to comply. You should actually be doing this already. You can use GDPR as a good “excuse” to bring yourself up to code