An ISO 27701 audit uses the same certification machinery as ISO 27001: an accredited certification body, a two-stage initial audit, and a three-year cycle of surveillance. If you have been through a 27001 certification, the shape will be familiar.
What is different is the evidence. A privacy audit samples records that security teams do not usually keep: requests from individuals, impact assessments, consent records, transfer decisions, and deletion at the end of a contract. Teams that are well prepared on security controls are often caught out here.
This article covers what to settle before booking, what each stage involves, what an auditor is likely to sample, how findings are handled, and what the cycle looks like after certification. It assumes your PIMS is built. If it is not, our guide to building a PIMS on your ISMS comes first.
What to settle before you book
Four decisions shape the audit, and each is harder to change once it has started.
The edition
ISO/IEC 27701 was revised in 2025. The editions differ in structure and in how they relate to ISO 27001. Ask the certification body directly which edition it will audit you against, what prerequisites it applies, and, if you hold a certificate under the earlier edition, what transition it offers. Get the answer in writing before you finalize your Statement of Applicability.
The certification body
Certification bodies are accredited by national accreditation bodies for specific standards. Accreditation for ISO 27001 does not automatically cover ISO 27701. Ask to see the accreditation scope, and confirm it names the privacy standard. A certificate from a body without that accreditation will carry less weight with buyers who check.
Combined or separate
If you hold ISO 27001 with the same body, you can usually audit both together. A combined audit shares the management system clauses, the interviews with leadership, and much of the security sampling, and adds privacy-specific time on top. A separate audit can make sense if the privacy program is owned by a different team on a different calendar, but it means repeating some of the same ground.
The scope
The scope statement should name the processing in scope and your role for each part: controller, processor, or both. Auditors check this early and test against it throughout. A scope that says "processor" while your Statement of Applicability includes controller controls, or the reverse, is a predictable stage 1 finding.
Stage 1: is the system ready to be audited
Stage 1 is mostly a documentation and readiness review. It may be remote, on site, or both. The auditor is deciding whether stage 2 can proceed, and planning it.
Expect to be asked for:
The scope statement, with roles stated
Your register of interested parties and applicable privacy obligations
The privacy policy and named accountability for privacy
The risk methodology, showing how privacy risk and harm to individuals are assessed
The Statement of Applicability, with justifications for each privacy control included or excluded
The processing inventory
Evidence that internal audit and management review have covered privacy
The stage 1 report lists areas of concern. These are not formal nonconformities, but if you do not address them before stage 2, they are likely to become one. Plan for a gap between the stages long enough to fix what stage 1 finds.
Stage 2: does the system operate
Stage 2 tests implementation and effectiveness. The auditor interviews control owners, observes processes, and samples records. Our articles on how auditors sample controls and what happens in an audit walkthrough describe the method; here is what it tends to land on in a privacy audit.
Records an auditor is likely to sample
- Not done:
Requests from individuals. A sample from the request log, each traced from receipt through identity verification to response, with dates.
- Not done:
Impact assessments. Completed assessments for recent launches or changes, and evidence that their findings reached the risk register.
- Not done:
Consent records, where any activity relies on consent: what the person saw, when, and how withdrawal works.
- Not done:
Processor agreements. For processors, signed customer agreements that match the template. For controllers, agreements with your own processors.
- Not done:
Subprocessor changes. The published list, a recent change, and the notice customers received.
- Not done:
Transfers. The transfer register and the basis recorded for a sample of transfers.
- Not done:
Deletion. A sample of customers who left, with evidence their data was returned or deleted as agreed.
- Not done:
Retention. A system where a retention period applies, and evidence that records beyond it were removed.
- Not done:
Privacy incidents. Any incident involving PII, how it was assessed for notification, and what was decided.
- Not done:
Training. Completion records for staff who handle PII.
Deletion and retention are the usual weak points. Teams can produce the schedule and the runbook. They cannot always produce proof that the runbook ran.
Interviews
Expect the auditor to speak with whoever owns privacy, someone who handles requests from individuals, an engineer who can explain how deletion works, and someone involved in vendor onboarding. Each person should be able to describe their part in their own words and point to the record. A privacy lead who can explain the policy but not the request log will prompt the auditor to look harder.
How findings are handled
Findings are usually graded as major or minor nonconformities, sometimes with opportunities for improvement noted alongside.
A major nonconformity generally means a requirement is not met at all, or a failure raises significant doubt about whether the system achieves its intended results. For example, no evidence that privacy risk was ever assessed. Certification is normally withheld until the correction is made and verified.
A minor nonconformity is a lapse that does not undermine the system as a whole. For example, two requests in a sample answered late without a recorded reason. You typically submit a corrective action plan, which the certification body accepts, and the fix is checked at the next audit.
A good corrective action plan names the root cause, the correction to the specific instance, the change that stops it recurring, an owner, and a date. "Retrain staff" is rarely a root cause.
After stage 2 and closure of any majors, the certification body's own decision process issues the certificate. The auditor recommends; the body decides.
After certification: the three-year cycle
A certificate is normally valid for three years, subject to surveillance.
Surveillance audits take place at least once a year. They are shorter than the initial audit and sample a portion of the system each time, along with any open findings and significant changes.
Recertification happens before the certificate expires and looks at the system as a whole again.
Between audits, the work is to keep operating. Keep the request log current, run impact assessments before launches, record deletions, and keep internal audit and management review on schedule. Tell the certification body about significant changes in scope or role, such as a new product that makes you a controller for data you did not previously hold.
One thing to keep in mind for customer conversations: the certificate states conformity with the standard for the stated scope. It is not a statement of legal compliance. Our guide to how ISO 27701 maps to GDPR explains where that line falls.
How TrustLynce helps
TrustLynce gives your auditor a single auditor portal for requests, evidence, and findings, so sampled records are shared in one place with a clear trail. Evidence is collected on a schedule and attributed, and privacy records sit in the data privacy workflows, so request logs and deletion records are ready before the auditor asks.