ISO/IEC 27701:2025: documentation and compliance requirements

This is what ISO/IEC 27701:2025 requires you to have, clause by clause, and what an auditor will ask to see for each of it. It covers 74 requirements across 13 areas.

It is deliberately not a checklist. A checklist asks whether you have something; this says what is required and what counts as evidence, which is the question that matters when you are building a system rather than testing one. If you would rather find out where you stand first, the same ground is covered by our free ISO/IEC 27701:2025 readiness assessment, which scores you out of 100.

4 Your organisation and the personal data you handle

Clauses 4.1, 4.2, 4.3, 4.4.

You must have written down the outside things that affect privacy here — laws, regulators, customers, technology, public expectations.

Evidence: A short list of these issues, with a note of when you last looked at it.

You must have written down the inside things — systems, skills, how you are organised, budget.

Evidence: The same list, covering internal issues.

You must have listed everyone with an interest — the people whose data you hold, regulators, customers, staff, suppliers.

Evidence: A list of these groups and what each needs from you.

You must know which privacy laws apply, in every country where you handle personal data.

Evidence: A register by country. Contract terms from customers. Sector rules.

For each activity, you must have written down whether you decide why and how the data is used, or whether you act on someone else's instructions.

Evidence: A written role determination per activity — controller, processor, or both. The duties differ, so settle this before answering the rest.

You must have written down what the privacy system covers — which activities, systems, sites and services.

Evidence: A scope statement, with the interfaces and dependencies identified.

You must know what your main processes are and how they fit together.

Evidence: A process map or a list with owners.

5 Leadership

Clauses 5.1, 5.2, 5.3.

Senior management must be able to point to privacy decisions they made in the last year.

Evidence: Management review notes. Money and people provided. Ask them directly.

You must have a written privacy policy for the management system.

Evidence: The policy, signed and dated. This is different from the privacy notice you give to the public.

It must be shared with your people.

Evidence: Where it is published. Acknowledgement records.

It must be clear who is responsible for what in privacy.

Evidence: Organisation chart. Responsibility list. A named owner for each processing activity and each risk.

Where the law requires a data protection officer, you must have appointed one who is independent and reports to the top.

Evidence: The appointment. Evidence of independence and of a direct reporting line. Their published contact details. Evidence they have the authority and resources to act.

6 Planning — privacy risk

Clauses 6.1.1, 6.1.2, 6.1.3, 6.2, 6.3.

You must have worked out what could stop the privacy system doing its job, and what opportunities there are.

Evidence: A risk and opportunity list at system level.

You must have a written way of assessing privacy risk, with the rules set before you start.

Evidence: The method, with acceptance criteria and scales.

The assessment must look at the harm to the PEOPLE whose data it is — not just the risk to your business.

Evidence: Consequences for individuals considered explicitly: discrimination, identity theft, financial loss, reputational damage, losing control of their own data. Assessing only business risk is the most common structural weakness.

You must have actually assessed the risks across your processing activities, with an owner for each.

Evidence: A privacy risk register with owners and levels, linked to the record of processing.

For each risk you are treating, you must have chosen what to do and which controls to use.

Evidence: A treatment plan naming the option, the controls from Annex A, the owner and the timescale.

You must be able to answer: Have the risk owners approved the plan and accepted the residual risk, in writing?

Evidence: Documented approval by the accountable owner, not by the privacy team on their behalf.

You must have a Statement of Applicability covering the Annex A controls that apply to your role.

Evidence: The Statement covering the controller controls, the processor controls and the shared controls, saying which are in, which are out, why, and whether each is implemented.

You must have set privacy objectives, and they must be able to be measured.

Evidence: Objectives with targets and numbers.

For each objective, it must be clear what will be done, by whom, by when, with what, and how you will judge it.

Evidence: An action plan covering all five points.

It must be defined when something changes — new processing, new system, new country, new sub-processor, a change of legal basis — you must plan it first.

Evidence: Change records with the privacy effects assessed beforehand.

7 Support

Clauses 7.1, 7.2, 7.3, 7.4, 7.5.

You must provide the people, money and tools the privacy system needs.

Evidence: Budget. Staffing. Tooling.

You must know what competence privacy-relevant roles need, and you must be able to show your people have it.

Evidence: Competence criteria for privacy, legal, IT, HR, marketing and customer-facing roles. Records.

You must be able to answer: Are the people who handle requests from individuals, and who assess breaches, specifically trained for it?

Evidence: Specialist training records.

You must be able to answer: Does everyone working for you know the privacy policy, their part in it and what happens if they do not follow it?

Evidence: Awareness programme covering staff and contractors. Completion records. Ask people.

You must have decided what to communicate about privacy, to whom, when and how.

Evidence: A communication plan or table.

You must have the documents and records the standard asks for.

Evidence: A list including the scope, policy, risk method, assessment and treatment results, Statement of Applicability, objectives, competence evidence, monitoring, audit and review records.

Those must be documents themselves protected, and is personal data inside them kept to a minimum.

Evidence: Access controls. Minimal personal data held in evidence files.

8 Running the system

Clauses 8.1, 8.2, 8.3.

You must have planned and put in place the processes needed to meet the privacy requirements.

Evidence: Documented processes and evidence they are performed.

You must control sub-processors and other third parties who handle personal data for you.

Evidence: A register of sub-processors and third parties. Contracts with the required terms. Due diligence before engagement and monitoring afterwards. Controls on onward transfer.

You must reassess privacy risk at set intervals and whenever something significant changes.

Evidence: A schedule with the interval. Assessment records with dates and the trigger.

You must be carrying out the privacy risk treatment plan, and recording the results.

Evidence: Treatment plan status with implementation evidence.

9 Checking how you are doing

Clauses 9.1, 9.2, 9.3.

You must have decided what you will measure, how, when and who evaluates it.

Evidence: A monitoring plan. Measures such as request response times, breach detection and notification times, training completion, sub-processor assessment currency, retention schedule adherence.

You must analyse the results rather than just collecting them.

Evidence: Analysis and evaluation records with actions arising.

You must audit the system and the applicable Annex A controls, over a cycle.

Evidence: An audit programme. Audit reports and findings.

The auditors must be independent of the work they audit, and competent in privacy.

Evidence: Auditor training and independence records.

Senior management must review the system at planned intervals.

Evidence: Review dates and attendance.

The review must cover everything the standard asks for.

Evidence: An agenda covering: previous actions, changes, performance, complaints from individuals, monitoring and audit results, risk assessment and treatment status, regulatory developments, resources, improvement.

The review must produce decisions and actions, not just minutes.

Evidence: Decisions and an action list with owners and dates.

10 Putting things right and getting better

Clauses 10.2, 10.1.

When something goes wrong, you must deal with it and work out why.

Evidence: Nonconformity and corrective action records covering complaints, late requests and breaches.

You must check whether the same weakness exists elsewhere, and check later that the fix worked.

Evidence: Evidence you looked wider. A follow-up record with a date.

You must be able to show the system is better than last year.

Evidence: Trends in requests, complaints, breaches, response times and audit findings.

Annex A Knowing what data you hold and why

Clause A.

You must have a record of every processing activity — what data, whose, why, who you share it with, where it goes and how long you keep it.

Evidence: A record of processing covering every operation, for your controller role, your processor role, or both. Purpose and legal basis for each. Categories of data and of people. Special or sensitive categories flagged. Sources. Recipients. Transfers with their safeguard. Retention per category.

That record must be kept up to date when processing changes, rather than reviewed once a year.

Evidence: Revision history and the triggers for updating.

You must have identified the legal basis for each purpose, and you must be able to justify it.

Evidence: The basis per purpose, with the reasoning. Note that basis cannot be swapped after the fact.

Where you handle special or sensitive categories, you must have identified the extra condition that allows it.

Evidence: The additional condition recorded, plus any national requirement.

You must only collect what you actually need for the stated purpose.

Evidence: Minimisation review of forms, fields and data structures.

Annex A Being open with people and getting consent properly

Clause A.

You must tell people what you do with their data, at or before the point you collect it.

Evidence: Privacy notices in the languages and channels you use, given at the right time.

The notice must cover everything it needs to, in plain language people can understand.

Evidence: The notice checked against the required content. Layered design where it is long.

Where you rely on consent, you must be able to show it was freely given, specific, informed and by a clear action.

Evidence: Consent records showing what was consented to, when, how, and which version of the notice was shown. No pre-ticked boxes.

People must be able to withdraw consent as easily as they gave it, and you must act when they do.

Evidence: The withdrawal mechanism. Records of withdrawals actioned, including downstream systems.

Where children's data is involved, you must handle consent and protection differently.

Evidence: Age checks and parental consent arrangements. N/A with a reason if not applicable.

Annex A Rights of the people whose data you hold

Clause A.

People must be able to get access to their data, and a copy of it.

Evidence: A request procedure with identity checks. A register with receipt and response dates.

People must be able to have data corrected, completed or erased.

Evidence: Correction and erasure records. Evidence erasure actually happened, including in backups and analytics stores.

People must be able to object, restrict processing, or ask for their data in a portable form.

Evidence: Objection, restriction and portability records.

You must meet the legal deadline for responding, and record any extension.

Evidence: Elapsed times per request. Extensions notified in time, with the reason.

Corrections and erasures must be passed on to the people you shared the data with.

Evidence: Records showing recipients were told.

Where you act on someone else's instructions, you must help them answer requests they receive.

Evidence: The arrangement with the controller, and records of assistance given.

Annex A Privacy by design, keeping data no longer than needed

Clause A.

Privacy must be considered when you design or change a system or service, before it is built.

Evidence: Privacy requirements in design, procurement and project gates, with real examples.

The default settings the must be private ones — least data collected, least shared, least visible.

Evidence: Default configuration evidence.

You must carry out a privacy impact assessment for high-risk processing.

Evidence: The trigger criteria and completed assessments.

You must have a retention schedule, and is data actually deleted when it expires.

Evidence: The schedule per data category. Evidence of actual deletion, including backups, archives and test environments. Secure disposal records.

Where you claim data is anonymised, it must be genuinely irreversible.

Evidence: The method used. Reversible pseudonymisation is still personal data.

Annex A Working with others, and moving data across borders

Clause A.

Where you act on someone else's instructions, you must process only on their documented instructions.

Evidence: Processing agreements defining the instructions. A procedure for what to do if an instruction looks unlawful.

Sub-processors must be authorised, and are the same duties passed down to them.

Evidence: Authorisation records. Sub-processor contracts with equivalent terms. Notification of changes.

Where personal data goes to another country, there must be a lawful mechanism for it.

Evidence: A transfer register with the mechanism for each. Standard contractual clauses in the current form, annexes properly completed.

You must have assessed whether the destination country actually protects the data, and added extra measures if not.

Evidence: Transfer impact assessments per destination. Extra technical or contractual measures where needed.

You must be able to answer: At the end of a service, is personal data returned or deleted as agreed?

Evidence: Deletion or return records at contract end.

Annex A When something goes wrong

Clause A.

You must be able to detect a personal data breach, and is there a route for staff and suppliers to report one.

Evidence: Detection arrangements. A reporting route that is known and used.

You must have criteria for deciding whether a breach must be reported, and to whom.

Evidence: The assessment criteria for notifying the regulator and the individuals.

You must keep a register of every breach, including those you decided not to report, with the reasoning.

Evidence: A breach register with the facts, the effects, the decision and the reasons.

You must be able to meet the notification deadline in every country you operate in.

Evidence: Notification records with timestamps. Where you act for someone else, the agreed time for telling them, written into the contract and tested.

You must review after a breach and change your controls as a result.

Evidence: Post-breach reviews. Control changes that followed. A tabletop test where there has been no real breach.

Using this document

Nothing above asks for a manual, a template pack, or a filing system. It asks for decisions that have been taken deliberately and can be shown to have been taken — which is a far smaller job than most organisations expect, and a different one.

Length is not compliance. A procedure nobody follows is worse than no procedure, because an auditor finds the gap between the two. The test we apply is whether the person who has to do the job recognises their own work in what is written down.