ISO 27001 Control 5.34: Privacy and Protection of PII

Alan Parker, ISO 27001 Consultant & Internal Auditor,
Helping UK SMEs hit ISO 27001 in 90 days.
B.Sc (Hons) Information Systems · Certified ISO 27001 Lead Auditor · CISMP · ITIL Expert · 30+ years in IT governance and security.
Read full bio →

Introduction

Ask most small businesses how they handle privacy and the answer comes back quickly: “We’re GDPR compliant.” Sometimes that is true. Often it means somebody wrote a privacy notice for the website a few years ago and nobody has looked at it since. And even when the GDPR work is genuinely solid, it is rarely the whole answer to what ISO 27001 control 5.34 is asking.

The control asks you to identify and meet the privacy requirements that apply to you. That depends on where you operate, where the people whose data you hold are based, what data you hold and what your customers have made you sign. For a UK business it will certainly include UK GDPR and the Data Protection Act 2018. For a business with staff or customers elsewhere, it can include a good deal more.

This page covers what the control requires, why it is wider than GDPR, the one document an auditor will almost always ask for, and the blind spot I find in nearly every organisation I work with. There is a free record of processing activities template further down.

What control 5.34 actually asks for

The control is one sentence. You must identify and meet the requirements for preserving privacy and protecting personally identifiable information (PII) that come from applicable laws, regulations and contracts. PII is the ISO term for what UK law calls personal data: anything that identifies a living person, directly or indirectly. In practice the control expects:

• Knowing which privacy laws apply. Based on where you operate, where the individuals are, and what you process. Not just the law of the country you are registered in.
• Knowing what PII you hold and why. Which categories of people, which data, which systems, which purposes, and who you share it with.
• Meeting the obligations. Lawful basis, transparency, retention, security, rights requests, breach notification, transfers. Whatever the applicable laws require.
• Assigning responsibility. Somebody who owns privacy, and staff who know enough to handle PII properly.
• Protecting it in practice. The technical and organisational measures that keep PII safe, which is where the rest of your ISMS comes in.

In the 2013 edition this was control A.18.1.4. The intent has not changed. ISO 27001 does not ask you to be a privacy expert; it asks you to recognise privacy as an obligation, find out what it requires of you, and show that you have acted on it. If you want a full privacy management system on top, that is what ISO/IEC 27701 is for, but nobody needs it to pass 5.34.

Where 5.34 sits among the compliance controls

Controls 5.31 to 5.36 deal with legal obligations and checking that you meet them. Privacy is the one most organisations already know about, which is exactly why it gets taken for granted.

5.31 finds the obligations; 5.34 handles the privacy ones. If your legal register under control 5.31 is done properly, privacy law will already be on it, and 5.34 is where you show what you did about it. Retention periods for personal data overlap with control 5.33, and the checks that it all keeps working belong to 5.35 and 5.36.

It is wider than GDPR

In 2025 I was working with a US client that was confident about its data handling. It had done the work on its customer data and could talk sensibly about it. What it had not realised was that a state law applied to personal information about residents of that state, and that it covered employees as well as customers. The company’s own staff records fell squarely inside it, and nobody had looked. Several US states have rules like this; Massachusetts’ regulation, 201 CMR 17.00, for example, expects any business holding personal information about Massachusetts residents to maintain a written information security programme.

That is the pattern. Privacy obligations come from several directions at once, and the one people know about tends to hide the others:

• Where the people are, not where you are. UK GDPR reaches beyond the UK: it applies to organisations established here, and to those outside the UK that offer goods or services to, or monitor, people in the UK. Many US state laws work in a similar way. A UK company with a sales team in the US, or a US company with staff in Europe, picks up the obligations of both.
• Employee data. The most overlooked category. HR records, payroll, pension, health and absence data, right to work checks, monitoring. It is PII, it is often sensitive, and it is subject to the same laws as customer data, plus employment law on top.
• Sector rules. Healthcare, financial services, education and telecoms all add privacy obligations of their own.
• Contracts. Your customers’ data processing agreements are privacy requirements too. If you signed a DPA promising to notify a breach within 24 hours, that is your obligation, whatever the law says.

So the first job under 5.34 is not to dust off the GDPR file. It is to ask, honestly, where your data subjects are and what you hold about them, and then find out which rules that brings into play. For most UK SMEs the answer will be UK GDPR, the Data Protection Act 2018, PECR for marketing, and whatever their contracts say. For anyone working across borders, it is worth an hour with someone who knows the other jurisdictions.

What the auditor will check, and what they will not

A certification auditor is not a data protection regulator, and will not audit your GDPR compliance article by article. That surprises people in both directions. Some expect a full privacy audit and over-prepare; others assume privacy is out of scope and under-prepare.

What the auditor is looking for is evidence that you recognise privacy as an obligation and have addressed it. The quickest way to test that is to ask for your record of processing activities, the ROPA. It is a document you should have by law, so it is a fair test. If it exists, is current and reflects the business the auditor has spent the day looking at, that tells them a great deal. If it does not exist, the auditor can reasonably conclude that you are not living up to the expectations of the standard, because a legal requirement you have not met is exactly what 5.34 is about.

From there the auditor will sample. Your privacy notice, how you would handle a subject access request, how a personal data breach would be assessed and reported, and how one category of PII is actually protected. They are looking for joined-up evidence, not perfection.

The ROPA: the document you should already have

Under Article 30 of UK GDPR, organisations must keep a record of their processing activities. There is an exemption for organisations with fewer than 250 employees, but it falls away if the processing is more than occasional, is likely to result in a risk to individuals, or involves special category or criminal offence data. Running payroll every month is not occasional, so in practice the exemption rarely helps anyone with staff.

A ROPA does not need to be elaborate. For each processing activity, it records:

• What the activity is and why you do it.
• Whose data it is: customers, prospects, employees, candidates, suppliers’ contacts.
• What categories of data are involved, and whether any of it is special category data such as health information.
• Your lawful basis.
• Who receives it, including the suppliers who process it for you.
• Whether it leaves the UK, and the safeguard that covers the transfer.
• How long you keep it.
• The security measures that protect it, in general terms.

For a 20-person business that usually comes to between ten and twenty lines. It is a morning’s work the first time, and a useful one, because building it forces the questions that 5.34 is really asking. Where is this data? Who can see it? Who did we share it with? Why are we still keeping it?

It also connects to the rest of the ISMS. The systems in the ROPA should appear in your asset inventory under control 5.9. The recipients should appear in your supplier register under control 5.19. The retention periods feed control 5.33. When an auditor finds the same picture in all four places, they stop worrying about this control.

The blind spot: PII in spreadsheets

Ask where personal data lives and people list their systems: the HR platform, the CRM, the payroll software. The systems are usually reasonably well protected. The problem is the data moving between them.

I was working with a company whose HR system did not talk to its payroll system, and neither talked to the pension provider’s portal. Every month somebody exported a spreadsheet from HR, reworked it, imported it into payroll, then produced another spreadsheet for the pension upload. Names, salaries, bank details, National Insurance numbers, all in flat files, every month.

My first concern was where those spreadsheets were stored. In most organisations, the honest answer is the Downloads folder of whoever ran the payroll, on a laptop, indefinitely, sometimes with a copy emailed to a colleague for checking. That is a full payroll history sitting outside every control the ISMS has.

In this case, it turned out they were doing it properly. The files were saved straight to a secure folder that only the two people who ran payroll could open, and they were deleted once the run was complete and reconciled. Nobody had written the process down, but it existed, it was followed and it could be shown. Writing it down took ten minutes and gave them good evidence for 5.34.

That is the exception, though. Look for spreadsheets of PII in these places:

• Exports and imports between systems that do not integrate: HR, payroll, pensions, benefits, finance.
• Mailing lists pulled from the CRM for a campaign and never deleted.
• Event and webinar registration lists.
• Test and development data copied from production. Real customer records in a test database are still real customer records.
• Shared inboxes, where CVs, ID documents and bank details arrive as attachments and stay forever.
• Reports run for a board meeting or a client, saved locally “for reference”.

For each, the questions are the same. Where is it stored, who can open it, how does it get there, and when is it deleted? The register below has a tab for exactly these flows, because they are the ones that never make it into a ROPA.

What auditors will look for

In an audit, I would typically work through 5.34.

1. Your ROPA. Does it exist, is it current, and does it match what I have seen elsewhere in the audit? If I have just watched you open the HR system and it is not on the ROPA, the ROPA is not current.
2. Your applicable requirements. How did you decide which privacy laws apply? Is the answer on your legal register, and does it reflect where your staff and customers actually are?
3. Privacy notices. One for customers and one for staff, at least. Do they match the ROPA?
4. A rights request. How would you handle a subject access request? Has one come in, and what happened?
5. A breach. How would a personal data breach be assessed and reported within 72 hours? This links straight to your incident process under control 5.26.
6. One flow of PII, traced. Pick something like payroll and follow it end to end: where it starts, every place it is copied, who can see it, and where it ends.

Common issues

• No ROPA at all, on the assumption that the 250 employee exemption applies. It almost never does.
• A ROPA written once for GDPR in 2018 and never updated. The systems and suppliers have all changed since.
• Privacy treated as GDPR only, with staff or customers in other jurisdictions ignored.
• Employee data left out of the ROPA entirely, because privacy is thought of as a customer matter.
• Payroll and pension spreadsheets sitting in Downloads folders and email.
• Real customer data copied into test environments.
• Customer DPAs signed with breach notification deadlines nobody internally knows about.
• Nobody clearly responsible for privacy, so rights requests and breaches are handled by whoever happens to see them.

The self-check

Five questions. If you cannot answer them today, an auditor will find that out for you.

• Can you produce your ROPA in the next ten minutes, and was it updated in the last year?
• Which privacy laws apply to you, and how did you decide?
• Where are your payroll and pension export files right now, and who can open them?
• If a customer’s contract requires breach notification within 24 hours, would the person handling the incident know that?
• Is any real customer data sitting in a test or development environment?

The third and fourth are the ones to sit with. Most organisations can talk about GDPR. Far fewer know where their own staff data goes once it leaves the HR system.

A worked example

The details below are typical rather than drawn from a single engagement. This is a composite of what a first proper look at 5.34 turns up in a business of this size.

A 30-person software company based in the UK, with five staff in the US and customers in the UK, Europe and North America. It has a privacy notice on its website, a GDPR policy written in 2018, and a cloud HR system, a separate payroll bureau and a US payroll provider for the American staff.

What the review found

• No ROPA. The company had assumed the small business exemption applied.
• Privacy had only ever been considered under UK GDPR. Nobody had looked at the US states where the five American employees lived.
• Monthly payroll exports were emailed to the bureau as password-protected spreadsheets, with the password sent in the next email.
• The development team used a copy of production data, including customer contact details, in its test environment.
• Two enterprise customer contracts required breach notification within 48 hours. The incident procedure said 72 hours, because that is what GDPR says.

What changed

• A ROPA built in a morning: 14 processing activities, with lawful basis, recipients, transfers and retention for each.
• An applicable laws review covering UK GDPR, the EU GDPR for European customers, and the relevant US state laws for the American staff, recorded on the legal register.
• Payroll files moved to the bureau’s secure upload portal, with local copies kept in a restricted folder and deleted after reconciliation.
• Test data replaced with masked data generated from production, under control 8.33.
• The incident procedure updated to check customer contract notification terms as part of the breach assessment.

About two days of effort, most of it on the US research and the test data. None of it required a privacy consultant, and all of it is evidence an auditor can see.

How control 5.34 links to other clauses and controls

• Control 5.31, Legal, statutory, regulatory and contractual requirements. Privacy law belongs on your legal register. 5.31 identifies the obligation; 5.34 is how you meet it.
• Control 5.33, Protection of records. Retention periods for personal data come from the same laws, and your retention schedule should match your ROPA.
• Control 5.9, Inventory of information and other associated assets. Every system on the ROPA should be in the asset inventory.
• Control 5.14, Information transfer. Payroll exports and spreadsheets sent to suppliers are information transfers, and the rules for sending them belong here.
• Control 5.19, Information security in supplier relationships. Suppliers who process PII for you are processors under GDPR. Your supplier assessment should cover both.
• Control 5.26, Response to information security incidents. A personal data breach is an incident with a legal clock attached.
• Control 8.10, Information deletion. Deleting the spreadsheets when the job is done is this control in action.
• Control 8.11, Data masking. and Control 8.33, Test information. How you keep real PII out of places it does not need to be.
• Clause 4.2, Understanding the needs and expectations of interested parties. Regulators, staff and customers are all interested parties with privacy requirements. Clause 4.2 is where you record that.

What I find in audits

About 1 in 10 of the software businesses I work with use real customer data in test or development environments. More detail is in my findings report.

Frequently asked questions

Sources and further reading

Official legislation, standards and guidance referred to on this page.

• UK GDPR Article 30: Records of processing activities. The legal requirement to keep a ROPA.
• Documentation. ICO guidance on records of processing activities.
• Report a breach. ICO guidance on assessing and reporting a personal data breach.
• International transfers. ICO guidance on sending personal data outside the UK.
• 201 CMR 17.00. Massachusetts standards for the protection of personal information of residents.
• ISO/IEC 27701:2025. The international standard for privacy information management.
• ISO/IEC 27001:2022, Information security management systems. The standard itself, published by ISO.

Internal Audit Service

Get an independent view of your ISO 27001 ISMS before you go into an audit.

“Alan from Iseo Blue truly came to our rescue. His support ahead of our internal audit was outstanding, and he helped us get our ISMS 100% ready for the Phase 2 audit.“

– Quartile.

✓ Gain confidence
✓ Audit plan
✓ Independent view
✓ An ISO 27001 requirement

✓ Audit findings report
✓ Recommendations
✓ Review meeting
✓ Fixed price

£2,500

+ VAT where applicable

View DetailsBook a discovery call