ISO 27701 Stage 1: what happens on the day, and what to have ready
ISO 27701 is an extension to ISO 27001, not a standalone privacy standard. Stage 1 audits reflect that: the auditor is testing whether your Privacy Information Management System sits credibly on top of a real ISMS. The Records of Processing Activities carry most of the weight, controller versus processor classification matters more than most organisations realise, and thin third-party assurance is the classic finding.
ISO 27701 is an extension of ISO 27001, not a standalone privacy standard. That single fact shapes the entire Stage 1 audit. The auditor is not evaluating a Privacy Information Management System (PIMS) in isolation. They are testing whether the PIMS sits credibly on top of an ISMS that already meets 27001, and whether the privacy-specific additions are coherent, documented, and integrated.
This piece walks through what happens on the day, what documentation matters most, and where organisations who treated 27701 as “GDPR plus a certificate” tend to trip. It is the fifth piece in the Audit Day series.
Key takeaways
- 27701 sits on top of 27001. Weaknesses in the base ISMS will surface in a 27701 audit, often more visibly than in the 27001 audit itself.
- The Records of Processing Activities is the pivotal artefact. Auditors spend disproportionate time here because Article 30 GDPR expectations overlap almost completely with 27701 requirements.
- Controller versus processor classification is not a paperwork detail. It drives which Annex A (controller) and Annex B (processor) controls apply, and auditors probe the classification with worked examples.
- Third-party processor assurance is the classic Stage 1 finding. DPAs are usually signed. Evidence of ongoing monitoring of those processors usually is not.
- Common Stage 1 finding: the ISMS is mature, the DPO exists, but the PIMS integration (how privacy risk feeds the ISMS risk register, how DPIAs feed programme decisions) is thin.
What the Stage 1 auditor is actually doing
ISO/IEC 27701:2019 (soon to be superseded by 27701:2025) is audited under the same ISO/IEC 17021-1 framework as other management-system standards. Stage 1’s formal objectives:
- Review the documented information required by 27001 (as the base) and 27701 (as the extension), including the PIMS scope, the privacy policy, the RoPA, the DPIA methodology, and the Statement of Applicability against 27701 Annex A and Annex B as applicable.
- Evaluate the organisation’s understanding of privacy-specific requirements and the controller/processor role classification.
- Confirm the internal audit programme covers privacy-specific clauses, not only the 27001 base.
- Identify Areas of Concern that would prevent Stage 2 from proceeding.
- Establish the Stage 2 audit plan including sampling of processing activities.
If the 27001 audit is happening simultaneously (combined audit), the auditor is doing both at once, with 27701-specific artefacts checked in addition to the ISMS baseline.
What is specifically different from ISO 27001 Stage 1
Organisations that assume 27701 audits are ISMS audits with a privacy chapter tend to underestimate what is being asked.
RoPA is a load-bearing document. In 27001, the risk register carries most of the weight. In 27701, the RoPA does. Every downstream control decision (retention, transfer, DPIA scoping, third-party assurance) flows from what the RoPA records. A weak RoPA cascades into weakness everywhere else.
Controller/processor classification is per processing activity. Organisations are usually both controllers (for their own operations) and processors (for services they provide to customers). The Statement of Applicability draws from Annex A (for controller processing) and Annex B (for processor processing) based on the classification. Getting this wrong at the SoA level is a Stage 1 finding.
DPIA methodology, not just DPIA outputs. Stage 1 checks the methodology: when a DPIA is triggered, what it covers, who approves it, how residual risk is treated. The auditor will not usually read every DPIA at Stage 1, but they will read the methodology and one or two worked examples.
Data subject rights procedures. Documented procedures for handling access requests, erasure, portability, objection, and rectification. The procedure needs to demonstrate meeting the one-month response window (Article 12 GDPR) with sensible escalation for complex requests.
Cross-border transfer mechanisms. For every transfer outside the EEA, the specific safeguard used (adequacy, SCCs, BCRs, EU-US Data Privacy Framework where applicable). References to Privacy Shield are a red flag: it was invalidated in July 2020.
Third-party processor assurance. Not just a signed DPA. Evidence of ongoing monitoring: periodic reviews, incident notifications, audit rights exercised, sub-processor changes tracked. This is where most organisations have paper compliance but thin actual assurance.
Documentation to have ready
Stage 1 auditors ask for the following, in addition to the full 27001 documentation set:
- PIMS scope statement (Clause 5.2 of 27701). Which processing activities and organisational units are in scope. Controller/processor classification per activity.
- Privacy policy (Clause 6.2 of 27701, extending 27001 Clause 5.2). Signed by top management, communicated, current.
- Records of Processing Activities covering everything in scope. See the DPC’s expectations for what defensible looks like.
- Privacy roles and responsibilities. DPO where required, privacy lead, joint controller agreements where relevant.
- PII risk assessment, integrated with or extending the ISMS risk assessment.
- DPIA methodology and worked examples where high-risk processing has been identified.
- Statement of Applicability against 27701 Annex A (controller) and Annex B (processor) as applicable.
- Data subject rights procedures with evidence of process, not just documentation.
- Third-party processor register with contracts, assurance evidence, and monitoring records.
- Cross-border transfer inventory with specific safeguards for each transfer.
- Retention schedules per data type, not “as per retention policy.”
- Consent management where consent is a legal basis, including how consent is recorded and withdrawn.
- Personal data breach procedures covering both regulator notification (72 hours under GDPR Article 33) and data subject notification where required.
- Privacy by design and default procedures for how new processing activities are assessed before deployment.
- Internal audit programme covering privacy-specific clauses, and reports demonstrating the programme is running.
- Management review outputs with privacy performance substantively covered.
The Article 30 RoPA is the artefact auditors spend most time on. The rest of the documentation flows from what the RoPA says.
Controller versus processor: getting the classification right
The single most common Stage 1 finding under 27701 is a Statement of Applicability that does not accurately reflect the organisation’s controller/processor mix.
Most organisations are both. A SaaS company is a controller for its own HR, finance, and marketing processing, and a processor for its customers’ data. A consultancy is a controller for its own operations and often a joint controller with clients for engagement-specific processing. A charity may be a controller for donor data and a processor for services it delivers to beneficiaries under contract.
Stage 1 auditors test classification by asking, for specific processing activities in the RoPA, whether the organisation is acting as controller or processor and how the SoA reflects that. A blanket “we are a controller” position rarely survives the third worked example.
The fix is not to over-classify. It is to record the classification per processing activity in the RoPA and let the SoA draw from Annex A or Annex B accordingly.
The third-party assurance gap
The second most common Stage 1 finding is third-party processor assurance that is contractual but not operational.
Signed data processing agreements are usually in place. Evidence of what happens after the DPA is signed is usually thin: no periodic reviews, no incident notification records, no audit rights exercised, no sub-processor change tracking, no review triggered when the processor changes hosting region or is acquired by another company.
Auditors ask for evidence of ongoing assurance. “We signed a DPA in 2022” is not evidence of ongoing assurance. What passes at Stage 1 is a documented process for periodic processor review with evidence the process has been executed.
A practical pre-Stage 1 checklist
Two weeks before Stage 1:
- The 27001 ISMS is either certified or Stage 2-ready. Everything on the ISO 27001 Stage 1 checklist applies here.
- The RoPA is current, complete, business-owned, and satisfies both Article 30 GDPR and 27701 requirements.
- Controller/processor classification is recorded per processing activity, and the Statement of Applicability draws from Annex A and Annex B accordingly.
- DPIA methodology exists and has been applied to at least one high-risk processing activity, with a documented output.
- Data subject rights procedures are documented and have been tested (either through real requests or a walk-through).
- Every third-party processor has a signed DPA and documented evidence of at least one review since the DPA was signed.
- Cross-border transfer inventory is current with specific safeguards for each transfer.
- Retention schedules are specific per data type.
- The DPO (or equivalent) is available during the audit and briefed on what to expect.
- Internal audit has covered the privacy-specific clauses and produced findings.
- Management review has included privacy performance as a substantive input.
If any of the above is not true, address it before Stage 1. Some (methodology, classification) is fast. Some (running processor reviews for every third party you have) takes weeks.
The Axlio Method at 27701 Stage 1
Stage 1 sits inside the Assure step of the Axlio Method. By this point, Understand (which processing activities exist, at what risk level, in what role), Assess (against 27701 and GDPR obligations), Prioritise (which processing activities and controls matter most), and Implement (the PIMS itself, sitting on the ISMS) should already have happened. Stage 1 is the first independent test.
Where Stage 1 raises significant issues on privacy specifically, the response is usually to loop back to Understand: the RoPA is where the misunderstanding of scope lives, and every downstream finding often maps to a RoPA gap.
Closing
ISO 27701 Stage 1 tests whether the PIMS is real or whether it is a privacy sticker on an ISMS. Organisations that built the PIMS deliberately, with a live RoPA and honest controller/processor classification, pass Stage 1 cleanly. Organisations that treated it as a documentation exercise discover during Stage 1 that the standard is more demanding of the base ISMS than they expected.
For support preparing for an ISO 27701 audit, or for a wider ISO 27701 or GDPR engagement, get in touch. Our RoPA piece covers the DPC’s specific expectations for the artefact 27701 Stage 1 auditors spend most of the audit on.
