Free set up for all new subscriptions before Nov 30th 2023. Save $1,000. Book a demo now

ISO 27001 Privacy Controls: Annex A 5.34 And ISO 27701 Guide

ISO 27001 Privacy Controls: Annex A 5.34 And ISO 27701 Guide

When your business handles personally identifiable information (PII), whether through identity verification, client onboarding, or background screening, you need more than good intentions to protect it. You need a structured framework. That’s exactly where ISO 27001 privacy controls come in, giving organisations a systematic approach to managing and securing sensitive data. For regulated industries like accounting, financial services, and legal, understanding these controls isn’t optional; it’s foundational to maintaining compliance with Australian privacy obligations and international standards.

ISO 27001’s Annex A includes specific controls that address privacy, most notably Annex A 5.34, which deals directly with the privacy and protection of PII. But ISO 27001 alone doesn’t cover every privacy requirement. That’s why the ISO 27701 extension exists, to bridge the gap between information security management and dedicated privacy management, aligning your practices with laws like the Australian Privacy Act and the GDPR.

At StackGo, we built our integration platform with these principles at its core. Our Privacy Layer ensures PII is never stored in your CRM, accessible only by MFA-authenticated admins, a direct reflection of the kind of controls ISO 27001 and ISO 27701 demand. This article breaks down what Annex A 5.34 requires, how ISO 27701 extends those requirements, and the practical steps to implement privacy controls that satisfy both your compliance team and your auditors.

Why ISO 27001 privacy controls matter

ISO 27001 privacy controls give your organisation a documented, auditable way to protect sensitive data rather than relying on informal policies that collapse under scrutiny. For businesses in regulated industries, particularly accounting, financial services, legal, and real estate, the stakes are concrete. You handle personally identifiable information (PII) daily, and every client file, identity check, and onboarding record carries real liability if mismanaged. A structured framework is the difference between demonstrating compliance confidently and scrambling to explain a breach after the fact.

The regulatory pressure on Australian businesses

Australian businesses face a growing stack of overlapping privacy obligations that make structured controls essential rather than optional. The Australian Privacy Act 1988 (and its ongoing reform proposals) sets baseline requirements for how organisations collect, store, use, and disclose personal information. Accounting firms face additional scrutiny under AUSTRAC’s AML/CTF regime, which demands robust client identity verification and record-keeping processes that align directly with what ISO 27001 addresses.

If you operate in a sector that touches personal financial data, identity documents, or health records, you are almost certainly subject to at least one regulatory framework that expects documented privacy controls.

Beyond domestic law, if your clients or partners operate across borders, you may also need to satisfy the EU General Data Protection Regulation (GDPR) or similar international standards. Meeting ISO 27001 requirements positions your organisation to demonstrate compliance across multiple frameworks simultaneously, rather than building separate processes for each one. This matters when clients ask for evidence of your security posture before signing an engagement letter.

The operational cost of getting it wrong

A privacy failure is not just a regulatory problem; it is an operational one. Data breaches in professional services can mean losing client trust, facing Office of the Australian Information Commissioner (OAIC) investigations, and absorbing the direct costs of notification, remediation, and potential penalties. The notifiable data breaches scheme under the Privacy Act means you have legal obligations to report breaches likely to cause serious harm, adding urgency to prevention.

Manual, fragmented compliance processes increase your exposure. When PII moves through spreadsheets, email threads, and unintegrated systems, the likelihood of unauthorised access, accidental exposure, or incomplete audit trails rises significantly. Regulated firms that rely on ad hoc processes often discover gaps only when an auditor or regulator asks for evidence that simply does not exist.

Why a structured framework outperforms ad hoc policies

A documented framework gives your team clear, repeatable procedures rather than leaving privacy protection to individual judgement calls. ISO 27001 requires you to identify information assets, assess risks, and apply controls proportionate to those risks, which means your privacy posture reflects actual threats rather than assumptions. This is precisely what auditors and regulators want to see: evidence that you have thought systematically about where PII sits, who can access it, and what protections are in place.

Structured controls also create accountability. When roles and responsibilities are documented and staff are trained against specific requirements, human error becomes easier to detect and correct before it escalates into a breach. Policies that sit in a shared drive but are never tested or reviewed provide little practical protection. ISO 27001’s continuous improvement cycle forces you to revisit and update controls as your business and the threat landscape change.

For businesses like accounting firms managing client identity records, or financial services providers running KYC workflows, this structure translates directly into operational confidence. You know exactly where PII is stored, who has accessed it, and whether those access events were authorised, because your framework demands that level of visibility from the outset.

What Annex A 5.34 requires

Annex A 5.34 sits within the people controls section of ISO 27001:2022 and carries a direct title: "Privacy and protection of PII." At its core, the control requires your organisation to identify and meet the requirements for preserving privacy and protecting PII in accordance with applicable laws and regulations. That scope is intentionally broad, because the control acts as a connector between your information security management system and your specific legal privacy obligations.

What Annex A 5.34 requires

The control does not define privacy requirements for you; it requires you to identify what those requirements are, document them, and show that your controls reflect them.

The core obligation

The control requires you to establish and implement a policy specifically addressing privacy and the protection of PII. This policy must be communicated to all relevant staff and must align with applicable laws, regulations, and contractual requirements. For Australian businesses, that means aligning your policy directly with the Australian Privacy Act 1988 and, where applicable, sector-specific regulations like AUSTRAC’s AML/CTF framework. The policy is not a one-time document; it must be reviewed and updated whenever your legal obligations or processing activities change.

Your organisation must also assign clear responsibility for privacy, whether through a dedicated privacy officer role or a formally named individual accountable for PII protection. Without that accountability, ISO 27001 privacy controls remain aspirational rather than operational, and auditors will notice the gap immediately.

What the control covers in practice

Annex A 5.34 expects you to address the full lifecycle of PII within your business, from the point of collection through to deletion or return. This includes documenting what PII you hold, the legal basis for processing it, and the retention periods that apply. You need procedures in place for handling data subject requests, such as requests to access, correct, or delete personal information, and your staff need to know how to respond within required timeframes.

The control also expects you to address third-party risk. If you share PII with vendors, contractors, or integration partners, you need contracts or agreements that bind those parties to appropriate privacy standards. This is especially relevant for accounting firms and financial services businesses that use cloud-based CRMs or identity verification platforms, where PII passes through external systems as part of daily operations. Documenting those data flows and the safeguards attached to each one is a core expectation under Annex A 5.34, not an optional extra.

How Annex A 5.34 maps to privacy laws

Annex A 5.34 does not operate in isolation. Its real value comes from how it connects your information security management system to the specific privacy laws that regulate your industry. Understanding those connections helps you implement ISO 27001 privacy controls that satisfy multiple regulatory requirements at once, rather than building separate compliance programs for each framework.

How Annex A 5.34 maps to privacy laws

The Australian Privacy Act 1988

The Australian Privacy Act establishes 13 Australian Privacy Principles (APPs) that govern how organisations collect, use, store, and disclose personal information. Annex A 5.34 maps directly to several of these principles. APP 1 requires you to have a clearly expressed and up-to-date privacy policy, which mirrors the control’s requirement to establish and maintain a documented privacy policy. APP 11 demands that you take reasonable steps to protect personal information from misuse, interference, loss, and unauthorised access or disclosure, which sits at the centre of what Annex A 5.34 asks you to demonstrate to an auditor.

Aligning your Annex A 5.34 policy with the Australian Privacy Principles gives you a single documented position that satisfies both your ISO 27001 auditor and the Office of the Australian Information Commissioner.

Access and correction rights fall under APP 12 and APP 13, mapping directly to the control’s requirement for procedures addressing data subject requests. For an accounting practice managing client identity records, these procedures are the practical workflows your staff follow when a client asks to view, correct, or delete their personal information within your systems.

AUSTRAC AML/CTF requirements

Australian businesses in the financial sector face additional obligations under AUSTRAC’s Anti-Money Laundering and Counter-Terrorism Financing Act 2006. AUSTRAC requires businesses to collect and verify customer identity information and retain those records for at least seven years. Annex A 5.34’s requirements around PII lifecycle management and defined retention periods align directly with these obligations, giving you a single framework to document both your security controls and your AML/CTF record-keeping procedures. For accounting firms facing the upcoming AUSTRAC regime, this overlap is a practical advantage rather than an additional burden.

GDPR alignment

If you process the personal data of EU residents, the General Data Protection Regulation adds another layer of requirements on top of domestic obligations. GDPR’s expectations around lawful basis for processing, data subject rights, and written data processor agreements map closely to Annex A 5.34’s scope. Implementing the control thoroughly positions your organisation to demonstrate GDPR compliance without constructing an entirely separate program, because the underlying documentation, accountability structures, and third-party contract requirements demanded by both frameworks overlap significantly.

How to implement Annex A 5.34 in practice

Implementing ISO 27001 privacy controls starts with understanding what you actually have before you write a single policy. Most organisations skip the discovery phase and jump straight to documentation, which means their policies describe an idealised version of their data practices rather than what actually happens day to day. Getting implementation right requires a sequence of deliberate steps, each building on the last.

Map your PII assets before writing policies

Before you draft any policy, you need a clear picture of every point in your business where PII enters, moves, and leaves. Walk through your systems and workflows to identify where client names, identity documents, financial records, and contact details are stored, who can access them, and whether third parties receive copies. For accounting firms and financial services businesses, this typically spans your CRM, cloud storage, email, identity verification platforms, and AML/CTF record-keeping systems.

Documenting your data flows before writing your policy ensures your controls reflect reality rather than assumptions.

Once you have that map, you can identify gaps between your current practices and what Annex A 5.34 requires, such as PII sitting in unsecured folders, staff accessing client records without documented authorisation, or vendor contracts that say nothing about data protection obligations.

Assign ownership and draft your privacy policy

After mapping your data flows, assign a named individual as accountable for privacy within your organisation. This does not have to be a full-time role, but the responsibility must sit with a specific person who reviews your privacy policy, monitors for changes to relevant laws, and owns the response process when issues arise. Without formal, documented ownership, your policy becomes a static document rather than an active control.

Your privacy policy must cover the legal basis for collecting each category of PII, the retention periods that apply, and the procedures staff follow to respond to data subject requests. Write it in plain language your team can actually use, communicate it formally to all relevant staff, and record that communication as evidence.

Embed controls into your daily workflows

Policies only work when they connect to how your team operates in practice. Build your retention schedules into your system configurations, restrict access to PII based on role, and set up a straightforward log to capture who accessed sensitive records and when. For businesses using CRM platforms, solutions that keep PII out of the CRM entirely and restrict access to MFA-authenticated administrators significantly reduce your implementation burden while satisfying the control’s core intent.

What auditors look for as evidence

When an auditor reviews your ISO 27001 privacy controls, they are not looking for polished documents alone. They want to see evidence that your controls are operational, tested, and consistently applied rather than written up and forgotten. Understanding what an auditor expects before the assessment begins gives you time to close gaps rather than explain them on the day.

Documentation auditors request first

The first thing an auditor asks for is your privacy policy and proof it has been communicated to staff. That means dated acknowledgement records, training logs, or confirmation emails, not just the policy itself sitting in a shared drive. They also want your data asset register or information inventory, showing every category of PII your business holds, where it is stored, who owns it, and how long you retain it before deletion or return.

Auditors treat a policy without communication evidence as a policy that does not exist for practical purposes.

Third-party contracts are another early request. If you share PII with vendors or integration partners, auditors expect written data processing agreements that specify what the third party can do with that data and how they protect it. Missing or generic contracts without privacy obligations are a common finding that delays certification.

Evidence that controls are active, not just documented

Your auditor will look beyond documents to confirm that your controls actually function in daily operations. They will ask to see access control logs showing who has been granted access to PII-bearing systems, when that access was last reviewed, and whether accounts were removed promptly after staff departed. Role-based access is expected, and auditors will ask you to demonstrate that staff only access PII relevant to their function rather than having broad, unreviewed permissions across your systems.

Response records for data subject requests are also on the list. If a client has asked to access or delete their personal information, your auditor wants to see a complete record of that request and your response, including the date received and the date resolved. Incomplete or missing records signal that your process exists on paper but not in practice.

Finally, auditors examine your incident and breach log. Even if no breaches have occurred, the log should reflect a live process, with entries for near-misses and documented decisions about whether notification obligations under the notifiable data breaches scheme were triggered. A completely blank log is not a clean record; it is a signal that your monitoring process is not actually running.

When to add ISO 27701 and what it changes

ISO 27001 provides a strong foundation for information security, but it was not designed as a dedicated privacy management standard. Annex A 5.34 points you toward privacy obligations without prescribing how to manage them at scale. ISO 27701 fills that gap by extending your Information Security Management System (ISMS) into a full Privacy Information Management System (PIMS), giving you a structured, auditable framework specifically built around the roles of data controller and data processor.

When to add ISO 27701 and what it changes

ISO 27701 does not replace ISO 27001; it requires ISO 27001 as its foundation and builds directly on top of it.

What ISO 27701 adds to your ISMS

ISO 27701 introduces additional controls and guidance that go well beyond what Annex A 5.34 covers on its own. Where ISO 27001 privacy controls establish the requirement to identify and meet privacy obligations, ISO 27701 maps out exactly how to do that across your entire data processing lifecycle. It introduces specific clauses for data controller responsibilities, such as defining the purpose and lawful basis for each processing activity, and separate guidance for data processor responsibilities, covering how you handle PII on behalf of another organisation.

The standard also introduces a set of privacy-specific controls in its Annex A and Annex B, covering areas like consent management, PII minimisation, data subject rights procedures, and privacy impact assessments. For an accounting firm or financial services business running client identity verification workflows, these controls translate into documented procedures for every stage of your PII handling, from the moment you collect a client’s identity documents through to their secure deletion at the end of the retention period.

Who needs ISO 27701 now

You should consider implementing ISO 27701 if your business processes significant volumes of PII, operates across multiple regulatory jurisdictions, or if your clients contractually require evidence of a formal privacy management system. Professional services firms facing the AUSTRAC AML/CTF regime will find ISO 27701 particularly useful because it provides a documented framework for demonstrating that your identity verification and record-keeping processes meet both security and privacy requirements simultaneously.

Businesses that act as data processors for other organisations, such as payroll providers, CRM vendors, or identity verification platforms, also benefit directly from ISO 27701 certification because it gives clients independent assurance that their PII is managed to an internationally recognised standard. If your current iso 27001 privacy controls are already operational and your audit cycles are running smoothly, adding ISO 27701 is a natural next step rather than a separate project.

Common mistakes and quick fixes

Even organisations with the best intentions make predictable errors when implementing ISO 27001 privacy controls. Most of these mistakes do not require a full program overhaul to fix; they just require you to identify the gap and apply a targeted correction before your next audit cycle or regulatory review.

Writing a privacy policy and never updating it

The most common mistake is treating your privacy policy as a finished document rather than a live control. Regulations change, processing activities expand, and staff turn over, but many organisations leave their original policy untouched for years. Auditors check version history and ask when the policy was last reviewed. If you cannot point to a recent review date with a named reviewer, that gap becomes a finding on the spot.

Schedule a formal privacy policy review at least annually, and trigger an unscheduled review whenever you adopt new software, enter a new market, or face a change in applicable law.

The quick fix is simple: add a review cycle to your ISMS calendar, assign the review to a named individual, and record each completed review in your document management system. That single habit closes one of the most common audit findings before it opens.

Storing PII in systems that have no business holding it

Many businesses accumulate personal information across CRMs, spreadsheets, email archives, and cloud storage without any deliberate decision about whether each system needs to hold that data. The result is a sprawling, uncontrolled PII footprint that is difficult to audit, secure, or delete on schedule. Annex A 5.34 requires you to know where your PII sits, which is impossible when it has spread into systems organically over time.

The quick fix starts with your data mapping exercise. Walk through each system and ask whether it genuinely needs to hold the PII currently stored there. For many businesses, shifting to a model where PII stays out of the CRM entirely and is only accessible through a controlled, MFA-protected layer removes the risk without requiring complex remediation work.

Ignoring vendor contracts until the auditor asks

Businesses frequently focus all their implementation effort on internal controls and policies while leaving third-party data processing agreements unsigned or generic. If a vendor handles PII on your behalf without a contract that specifies their obligations, you are exposed both under Annex A 5.34 and under the Australian Privacy Act’s accountability principles.

Fixing this requires a simple vendor audit: list every third party that receives or processes PII, check whether a written data processing agreement exists for each one, and update or create contracts where they are missing.

iso 27001 privacy controls infographic

A simple way to move forward

ISO 27001 privacy controls give you a structured, auditable approach to protecting PII across every part of your business. The steps are clear: map your data, assign ownership, document your policies, and test that your controls actually run day to day. Adding ISO 27701 when your volume or regulatory exposure justifies it extends that foundation into a dedicated privacy management system that satisfies multiple frameworks at once.

For regulated businesses in Australia, the most practical move is to start with your client identity verification workflow. That is where PII enters your systems, where your AML/CTF obligations concentrate, and where a poorly integrated process creates the most exposure. A solution that keeps PII out of your CRM and runs verification directly from your existing software removes a significant layer of risk without adding complexity.

See how IdentityCheck handles AUSTRAC Tranche 2 AML/CTF compliance inside your current systems

More Posts

Share:

Stay connected to StackGo

Related Posts