Control Definition
The organization must identify the requirements for preserving privacy and protecting personally identifiable information (PII) that applicable laws, regulations, and contracts impose on it, and must meet those requirements through dedicated policies, procedures, and the technical and organizational measures they call for.
Control Objective
To keep every processing of personally identifiable information compliant with the privacy laws, regulations, and contractual commitments that apply to it.
What This Really Means
This is one row in Annex A that opens an entire second rulebook. Security asks "is the data protected?"; privacy asks "should you be doing this with it at all?" — and the two questions have different answers more often than teams expect. Personal data can be encrypted, access-controlled, and flawlessly backed up while still being unlawfully collected, used for a purpose nobody consented to, or kept years past any legitimate need. A.5.34 exists to make the ISMS answer the second question, for every set of personally identifiable information the organization touches: customers, employees, candidates, users, and the contacts hiding in CRMs and mailing lists.
In practice the control asks for four foundations. First, know what PII you hold: an inventory or processing map recording what data, about whom, collected why, on what lawful basis, stored where, shared with which processors, and kept how long — the artifact GDPR calls a record of processing activities, and a sound idea under any law. Second, know which rules apply: privacy statutes and the data protection clauses in customer contracts, identified through the A.5.31 legal register — GDPR if you touch EU residents, India's DPDP Act, the Gulf PDPLs, plus sectoral rules. Third, a topic-specific policy for privacy and PII protection inside the organization, paired with the outward-facing privacy notices that tell individuals what you do with their data. Fourth, a named responsible role — a data protection officer or privacy officer, formally mandated in several regimes — who guides the organization and fronts regulator and individual contact.
Around those foundations sits the operational machinery: handling rights requests (access, correction, erasure, and their local variants) within statutory deadlines; capturing and honoring consent where consent is the basis; enforcing retention limits and disposal through A.5.33 and A.8.10; binding processors with data processing agreements; checking cross-border transfers against each law's conditions; and wiring breach-notification duties into incident response, because a PII breach starts a regulatory clock on top of the technical response. Organizations that want this machinery formalized and certifiable extend their ISMS with ISO 27701 — the privacy information management bolt-on built for exactly this purpose.
One boundary keeps expectations honest: a certification auditor does not certify you GDPR- or DPDPA-compliant — no ISO audit does that. What they verify is that the ISMS identified the applicable privacy requirements and operates real measures against them. The heart of the control at audit: the PII inventory exists and is current, the responsible role is named and reachable, one rights request can be traced end to end, and the incident procedure knows its notification clocks.
Why It Matters
Privacy is where a security program's failures convert most directly into legal exposure. Regulators levy fines and can order processing stopped; individuals can complain, litigate, and escalate; and a breach involving PII triggers dual obligations — contain the incident and notify authorities and affected people on statutory deadlines that do not pause while you investigate. An organization that never mapped its PII discovers, mid-incident, that it cannot even say whose data was exposed.
The commercial stakes are just as real. Enterprise customers run privacy due diligence before signing, data processing agreements flow obligations down to you, and a fumbled rights request is a self-inflicted regulatory contact: the requester who gets silence usually writes to the regulator next. Trust, once spent here, is expensive to rebuy.
Organizations that treat privacy as a website policy rather than an operated control face:
- •Regulatory fines and orders – privacy authorities impose substantial penalties and can suspend processing or transfers, and enforcement is increasingly active across the EU, India, and the Gulf
- •Missed breach-notification deadlines – statutory clocks, some as short as 72 hours, expire while teams debate whether the incident "counts", stacking a notification violation on top of the breach
- •Mishandled rights requests – access or erasure requests that die in shared inboxes become regulator complaints with the evidence trail already written by the requester
- •Contractual breach – violating a data processing agreement hands enterprise customers audit rights, indemnity claims, and termination leverage
- •Unlawful cross-border transfers – moving personal data to a jurisdiction without a valid transfer mechanism exposes the organization even when the data is never breached
Regional Compliance Context
India. The DPDP Act 2023 builds a consent-centric regime: Data Fiduciaries must collect personal data with notice, honor Data Principals' rights (access, correction, erasure, grievance redressal), and answer to the Data Protection Board; the DPDP Rules were notified in 2025 and full compliance obligations land by 13 May 2027 — a phase-in worth planning against now, not in 2027. Organizations designated Significant Data Fiduciaries carry a heavier tier: a data protection officer based in India, independent data audits, and periodic data protection impact assessments. The DPDPA applies to digital personal data without GDPR-style residency carve-outs by sector, so most India-connected ISMS scopes will include it.
Gulf and EU. Saudi Arabia's PDPL and the UAE federal PDPL both impose consent-first processing rules, breach notification duties, and conditions on transfers out of the country — relevant the moment a Gulf customer or entity enters scope. Anyone serving EU or UK residents inherits GDPR's machinery: lawful bases for each processing activity, rights deadlines, processor contracts, and 72-hour authority notification for reportable breaches. One processing map with a jurisdiction column handles all of these better than parallel privacy programs.
Implementation Guidance
Inventory PII and Map Every Processing Activity
Run a data-mapping exercise across functions — HR, sales, marketing, support, product, finance — recording for each processing activity: the data categories, whose data, the purpose, the lawful basis, storage locations, recipients and processors, cross-border destinations, and retention. A spreadsheet per the record-of-processing pattern works at small scale; data discovery and privacy management tools help once sprawl outgrows interviews. This map is the foundation every other step builds on.
Identify the Privacy Requirements That Apply to You
Through the A.5.31 legal register, enumerate the privacy laws engaged by where you operate, whose data you hold, and what your contracts promise: DPDPA for India-connected processing, GDPR for EU/UK residents, Gulf PDPLs, sectoral rules, plus the data protection clauses and DPAs in customer agreements. Break each source into discrete obligations — notice, consent, rights deadlines, breach notification, transfer conditions — rather than listing statute names.
Publish the Privacy Policy and Outward-Facing Notices
Write a topic-specific internal policy covering how the organization collects, uses, shares, retains, and protects PII, approved and communicated like any A.5.1 policy. Pair it with external privacy notices at every collection point — website, product, job applications, employee onboarding — that say in plain language what is collected, why, on what basis, and how to exercise rights. The internal policy and the public notice must describe the same reality.
Appoint and Empower a Responsible Privacy Role
Name the person accountable for privacy — a data protection officer where law requires one (GDPR criteria, DPDPA Significant Data Fiduciaries) or a privacy officer otherwise — with a defined reporting line, access to management, and enough independence to push back on processing. Publish their contact in notices and grievance channels. In smaller organizations this is a hat, not a hire, but the hat must sit on a named head.
Operationalize Data Subject and Data Principal Rights
Build one intake channel for rights requests — access, correction, erasure, objection, grievance — with identity verification, an SLA tracker against each law's deadline, and fulfillment workflows that actually reach the systems holding the data. Test the pipeline before the first real request: trace a dummy erasure from intake through every system in the data map. Requests arriving through support tickets and personal inboxes must route into the same channel.
Embed Privacy Into the Data Lifecycle and Supplier Chain
Enforce minimization at collection, retention limits and disposal through A.5.33 and A.8.10, masking or pseudonymization for non-production use under A.8.11, and access restricted to roles with a processing purpose. Bind every processor with a data processing agreement, keep the processor list synchronized with the data map, and check cross-border transfers against each applicable law's mechanism before data moves — including transfers hidden inside SaaS tooling.
Wire Breach Notification Into Incident Response and Review the Program
Extend incident procedures under A.5.24 with a PII branch: criteria for recognizing a personal data breach, who assesses notifiability, regulator and individual notification templates, and the statutory clocks per jurisdiction. Drill it annually alongside incident exercises. Review the whole privacy program on a cadence — and when maturity or customer demand justifies it, formalize it as a PIMS under ISO 27701, which extends the existing ISMS rather than starting over.
Audit Evidence
During your ISO 27001 certification audit, auditors will expect to see the following evidence to demonstrate compliance with A.5.34:
Documentation
- PII inventory or processing map covering data categories, purposes, lawful bases, locations, processors, transfers, and retention
- Topic-specific privacy policy plus the outward-facing privacy notices used at collection points
- Appointment record for the DPO or privacy officer, with role description and reporting line
- Rights request log showing intake dates, identity verification, actions taken, and closure within deadline
- Data processing agreements with processors, and transfer assessments or mechanisms for cross-border flows
Interviews
- DPO or privacy officer on how applicable laws were identified, how the data map stays current, and how regulator contact would run
- A process owner in HR or marketing on what PII their function collects, on what basis, and how long it is kept
- Incident manager on how a personal data breach is recognized and how notification deadlines are met
Observations
- A rights request traced end to end through the intake channel, verification, fulfillment across systems, and timely response
- A live collection point — signup form, career page, onboarding flow — checked against the notice and consent records behind it
- The processor list compared against signed DPAs and the data map, hunting for tools processing PII outside contract
Practitioner Insights
The misunderstanding I correct most often: teams expect the ISO 27001 audit to bless them as GDPR or DPDPA compliant, and it never does — certification verifies that your ISMS identified its privacy obligations and operates measures against them, not that a lawyer would sign off on your processing. The failure pattern that follows is predictable: a polished privacy policy on the website with no PII inventory behind it. When I pick one processing activity — say, candidate data in recruitment — and ask where it lives, what the lawful basis is, and when it gets deleted, the policy-only organizations have no answer. The inventory is the control; the policy is its cover page.
Small organizations stall on this control because they imagine data mapping needs enterprise tooling — it needs one workshop and one spreadsheet. Get the owners of HR, sales, marketing, and support in a room for an afternoon, walk each function through what personal data it touches, and you will have 80 percent of the map plus a list of surprises, usually marketing exports and candidate CVs in personal drives. The other early win is appointing the rights-request channel before the first request arrives; the requests that turn into regulator complaints are almost always the ones that sat unrecognized in a shared inbox while the statutory clock ran.
Common Challenges & Solutions
Challenge
Nobody knows where all the PII actually lives — it is scattered across SaaS tools, spreadsheets, exports, and inboxes.
Solution
Start with a function-by-function mapping workshop to capture the known systems, then sweep for the unknown: SSO and expense records reveal unsanctioned SaaS, and data discovery tooling can scan stores for PII patterns at scale. Triage findings into systems of record, tolerated copies, and data to delete. The map will never be perfect — make it current, owned, and refreshed on a cadence instead.
Challenge
Multiple privacy laws apply at once, with different definitions, deadlines, and transfer rules.
Solution
Build one program with a highest-common-denominator core — inventory, notices, rights handling, breach response, DPAs — then layer jurisdiction deltas as register entries: a stricter deadline here, a consent nuance there, a transfer condition for one corridor. Track the deltas in the A.5.31 register with owners. Parallel per-law programs duplicate work and drift apart; one program with documented variations survives audits and growth.
Challenge
Rights requests arrive through random channels — support tickets, social media, personal emails — and statutory deadlines start running unnoticed.
Solution
Publish one intake channel in every notice, then train the perimeter: support, reception, sales, and social teams need a one-line rule — anything that smells like a privacy request gets forwarded to the channel same day. Log every request with its legal deadline on arrival and track aging weekly. The deadline runs from receipt by the organization, not from when the right team finally notices.
Challenge
Consent is claimed as the lawful basis, but nobody can produce a record of who consented to what, when.
Solution
Instrument every consent-based collection point to capture the moment: identity, timestamp, the notice version shown, and the specific purposes agreed — and make withdrawal as easy as granting, with downstream systems honoring it. Where reliable consent records cannot be reconstructed, treat the data honestly: re-permission it or stop the processing. A consent claim without a record is, to a regulator, no consent at all.
Challenge
Processors and sub-processors handle PII without signed data processing agreements, or outside what the agreements allow.
Solution
Reconcile three lists — the data map's recipients, the vendor register, and signed DPAs — and close every gap with a contract or an offboarding. Make a DPA a precondition of procurement for any tool touching personal data, and require processors to disclose and flow obligations down to their sub-processors. Re-run the reconciliation periodically; SaaS adoption recreates the gap faster than annual reviews catch it.
