What is ISO 27001 Annex A 5.34?
ISO 27001 Annex A 5.34 requires organizations to identify and meet privacy and protection requirements for Personally Identifiable Information (PII) according to applicable laws, regulations, contracts and business requirements.
PII is information that can identify an individual directly or indirectly.
Examples include:
- Name
- Email address
- Phone number
- Address
- Government identification numbers
- Employee information
- Customer information
- IP addresses, where applicable
- Online identifiers
- Financial information
- Authentication-related information
- Health information
- Biometric information
- Customer records
The exact definition of personal information varies by applicable law and jurisdiction.
Simple explanation
If your organization collects, stores, uses, transfers or deletes personal information, you need to know what privacy requirements apply and ensure that the information is handled accordingly.
Why is Annex A 5.34 Important?
Organizations increasingly process personal information through:
- Websites
- SaaS applications
- Mobile applications
- HR systems
- CRM platforms
- Payment systems
- Cloud platforms
- Marketing platforms
- Customer support systems
- Analytics tools
- Third-party service providers
Improper handling of PII can result in:
- Privacy violations.
- Data breaches.
- Regulatory penalties.
- Customer complaints.
- Contractual violations.
- Loss of customer trust.
- Security incidents.
- Legal disputes.
For startups, privacy requirements can become particularly important when selling to customers in different countries.
Simple principle
Know what personal information you collect, why you collect it, where it goes, who can access it, how long you keep it, and when it must be deleted.
What is PII?
PII means Personally Identifiable Information.
It generally refers to information that identifies, relates to, describes, or can reasonably be linked to an individual, depending on the applicable legal framework.
Examples
| Category | Examples |
|---|---|
| Identity | Name, username, government ID |
| Contact | Email, phone, address |
| Employment | Employee ID, job title, employment records |
| Financial | Bank information, payment-related information |
| Online identifiers | Account IDs, device identifiers, certain IP addresses |
| Location | GPS/location information |
| Health | Medical or health information |
| Biometric | Fingerprints, facial recognition data |
| Customer data | User profiles, account information |
| Communications | Customer support conversations |
Not every piece of information is treated identically under every privacy law.
The organization should determine applicability based on the jurisdictions and activities involved.
A.5.34 Is About More Than Security
A common mistake is to treat privacy as simply:
“Protect personal data with passwords and encryption.”
Security is important, but privacy also concerns how and why personal information is processed.
For example:
A company may securely store an individual’s email address.
But it may still have a privacy issue if it:
- Collected the information without an appropriate basis.
- Uses it for an incompatible purpose.
- Keeps it indefinitely without justification.
- Shares it with unauthorized third parties.
- Fails to provide required notices.
- Does not honor applicable individual rights.
Therefore:
Security protects PII. Privacy governs appropriate processing of PII.
What Does Annex A 5.34 Require?
The organization should identify and comply with applicable privacy and PII protection requirements.
These requirements may come from:
Laws and Regulations
Depending on the organization’s activities and locations, this may include applicable privacy legislation such as:
- GDPR
- UK GDPR
- India Digital Personal Data Protection framework
- CCPA/CPRA
- Other applicable national or state privacy laws
The specific legal requirements depend on the organization’s jurisdiction, activities, customers and data processing.
Contracts
Customers may require:
- Data Processing Agreements.
- Privacy commitments.
- Security requirements.
- Data-location requirements.
- Breach notification obligations.
- Restrictions on subcontractors.
- Data deletion requirements.
Internal Requirements
The organization may also establish:
- Privacy policies.
- Data handling standards.
- Retention requirements.
- Access restrictions.
- Data classification rules.
- Privacy review procedures.
Important Privacy Questions
For each important PII processing activity, the organization should understand:
- What PII do we collect?
- Whose PII is it?
- Why do we collect it?
- What is the applicable legal basis or authorization?
- How is it used?
- Where is it stored?
- Who can access it?
- Who do we share it with?
- Which suppliers process it?
- How long do we retain it?
- How is it protected?
- How is it deleted or disposed of?
- What rights do individuals have?
- How do we respond to privacy requests?
- What happens if there is a privacy incident?
Activities Required to Implement A.5.34
Step 1 — Identify PII
Start by identifying where personal information exists.
Look at:
- Customer databases.
- CRM.
- HR systems.
- Payroll systems.
- Email.
- Support platforms.
- Application databases.
- Cloud storage.
- Marketing platforms.
- Analytics systems.
- Logs.
- Backups.
- Development environments.
- Third-party platforms.
Step 2 — Create a PII Inventory
A startup can create a simple inventory.
| PII | Data Subject | Purpose | System | Owner |
|---|---|---|---|---|
| Name | Customer | Account management | SaaS application | Product |
| Customer | Account communication | Application | Customer Success | |
| Employee data | Employee | HR administration | HR platform | HR |
| Billing information | Customer | Billing | Billing system | Finance |
| Support conversations | Customer | Customer support | Helpdesk | Support |
This provides visibility into where personal information is processed.
Step 3 — Determine Applicable Requirements
Determine which privacy laws, regulations and contracts apply.
For example, a SaaS startup may have:
- Employees in India.
- Customers in the United States.
- European customers.
- Cloud infrastructure in multiple regions.
The startup should not assume that one privacy framework automatically covers everything.
It should identify the requirements applicable to its actual activities.
Step 4 — Define the Purpose of Processing
Personal information should have a defined purpose.
Example:
Email address
Purpose:
Creating and managing a customer account and communicating important service information.
The organization should avoid collecting personal information simply because:
“We might need it someday.”
Step 5 — Establish Appropriate Privacy Notices
Depending on applicable requirements, organizations may need to provide individuals with information about:
- What data is collected.
- Why it is collected.
- How it is used.
- Who receives it.
- Retention.
- Individual rights.
- Contact information.
- Other required disclosures.
For a website, this may be reflected in:
- Privacy Notice.
- Cookie Notice.
- Consent mechanisms where applicable.
- Data-processing disclosures.
Step 6 — Control Access to PII
PII should only be accessible to people who need it.
Use:
- Least privilege.
- Role-based access.
- MFA.
- Privileged access controls.
- Periodic access reviews.
- Logging.
- Access approval.
- Timely access removal.
For example:
A software developer may not need unrestricted access to the complete production customer database.
Step 7 — Protect PII
Appropriate safeguards may include:
Technical Controls
- Encryption.
- Access control.
- MFA.
- Logging.
- Monitoring.
- Data masking.
- Tokenization where appropriate.
- Secure backups.
- Endpoint security.
- Network security.
Organizational Controls
- Privacy policies.
- Security policies.
- Employee training.
- Supplier agreements.
- Data retention rules.
- Incident response procedures.
- Privacy assessments.
Controls should be proportionate to the risk and applicable requirements.
Step 8 — Manage Third-Party Processors
Many organizations do not process PII entirely themselves.
A SaaS startup may use:
- Cloud providers.
- CRM platforms.
- Email providers.
- Payment processors.
- Customer-support systems.
- HR platforms.
- Analytics providers.
- Marketing platforms.
The organization should understand:
Which third parties receive or process our PII?
Where applicable, contracts should establish appropriate privacy and security obligations.
Step 9 — Establish Retention and Deletion Rules
PII should not automatically be retained forever.
Define:
- Retention period.
- Business/legal reason for retention.
- Deletion process.
- Backup considerations.
- Archival requirements.
- Legal hold requirements where applicable.
Example:
Customer account data is retained according to the organization’s documented retention requirements and applicable contractual/legal obligations.
Step 10 — Manage Individual Privacy Requests
Depending on applicable law, individuals may have rights concerning their personal information.
Examples may include rights relating to:
- Access.
- Correction.
- Deletion.
- Restriction.
- Objection.
- Portability.
The exact rights and exceptions depend on the applicable legal framework.
Organizations should establish a process for receiving, verifying, assessing and responding to applicable requests.
Step 11 — Manage Privacy Incidents
A privacy incident may include:
- Sending PII to the wrong recipient.
- Unauthorized access.
- Lost device containing personal data.
- Database exposure.
- Incorrect permissions.
- Accidental disclosure.
- Compromised account.
- Third-party data breach.
The organization should have an incident-management process that considers applicable privacy notification obligations.
Startup Example
Consider a 50-person SaaS company.
The company collects:
- Customer names.
- Email addresses.
- Business contact details.
- User account information.
- Support conversations.
- Employee information.
It uses:
- Cloud infrastructure.
- CRM.
- Helpdesk platform.
- Email service.
- Analytics platform.
- HR system.
The company creates a PII inventory.
Example
Customer email
→ Collected during account registration
→ Stored in SaaS database
→ Used for account communication
→ Accessible to authorized support staff
→ Backed up according to backup requirements
→ Shared with selected service providers where applicable
→ Retained according to documented requirements
→ Deleted or anonymized according to applicable retention requirements
This gives the organization a clear understanding of the information lifecycle.
Startup-Focused Quick Summary
For a startup, begin with a simple PII lifecycle:
Collect
↓
Use
↓
Store
↓
Access
↓
Share
↓
Retain
↓
Delete
At every stage, ask:
Is this necessary, authorized, secure and compliant with applicable requirements?
Example PII Processing Register
A startup can maintain a simple processing register.
| Data | Data Subject | Purpose | System | Shared With | Retention | Security |
|---|---|---|---|---|---|---|
| Name | Customer | Account management | SaaS platform | Selected processors | Defined period | Access control |
| Customer | Communication | SaaS platform | Email provider | Defined period | Encryption/MFA | |
| Employee data | Employee | HR | HR system | Payroll provider | Legal/business requirement | Restricted access |
| Support data | Customer | Support | Helpdesk | Helpdesk provider | Defined period | RBAC |
| Billing data | Customer | Billing | Billing platform | Payment provider | Applicable requirements | Restricted access |
PII Data Flow
For a SaaS application, a simplified data flow may look like:
Customer
↓
Web Application
↓
Application Database
↓
Cloud Infrastructure
↓
Support / CRM Systems
↓
Third-Party Processors
↓
Backup / Archive
↓
Deletion
The organization should understand each stage.
This is particularly important when personal information crosses:
- Countries.
- Cloud environments.
- Business units.
- Suppliers.
- Applications.
Privacy Risk Assessment
For higher-risk processing, organizations may need a more detailed privacy assessment depending on applicable requirements.
Consider:
| Question | Example |
|---|---|
| What data? | Customer identity information |
| Who is affected? | Customers |
| Why processed? | Account management |
| Sensitivity | Medium |
| Volume | 100,000 users |
| Access | Support + Engineering |
| Third parties | Cloud + CRM |
| International transfer | Possible |
| Retention | Defined period |
| Main risk | Unauthorized disclosure |
| Controls | RBAC, MFA, encryption, monitoring |
Where required by applicable law, a formal Data Protection Impact Assessment or similar privacy assessment may be appropriate.
Audit Evidence for A.5.34
An auditor may review:
Governance
- Privacy Policy.
- Data Protection Policy.
- Privacy Governance Procedure.
- Data Protection Roles and Responsibilities.
- Privacy training records.
Data Inventory
- PII inventory.
- Data flow diagrams.
- Data processing records.
- Data classification records.
- Application/data inventory.
Legal and Contractual
- Applicable privacy requirements.
- Data Processing Agreements.
- Customer contracts.
- Supplier agreements.
- Privacy assessments.
- Cross-border transfer documentation where applicable.
Technical Controls
- Access control.
- MFA.
- Encryption.
- Logging.
- Monitoring.
- Database permissions.
- Data masking where applicable.
Operational Evidence
- Privacy request records.
- Data deletion records.
- Retention reviews.
- Privacy impact assessments.
- Supplier assessments.
- Incident records.
- Privacy incident assessments.
What an Auditor May Ask
About PII
“What personal information does your organization process?”
“Where is PII stored?”
“Who has access to it?”
“How do you identify PII?”
About Privacy Requirements
“Which privacy laws and contractual requirements apply to your organization?”
“How do you keep these requirements up to date?”
“How do you determine which requirements apply to a particular processing activity?”
About Suppliers
“Which third parties process personal information on your behalf?”
“How do you assess them?”
“What privacy and security requirements are included in their contracts?”
About Retention
“How long do you retain customer data?”
“How is personal information deleted?”
“What happens to PII in backups?”
About Individual Rights
“How would an individual submit a privacy request?”
“Who handles the request?”
“How do you verify the identity of the requester?”
About Incidents
“What happens if personal information is accidentally disclosed?”
“How do you determine whether a privacy notification is required?”
Common Mistakes in Implementing A.5.34
1. Treating privacy as only an IT security issue
Privacy involves more than encryption and access control.
It also involves:
- Purpose.
- Transparency.
- Retention.
- Sharing.
- Individual rights.
- Legal requirements.
2. Not knowing where PII exists
A company cannot effectively protect information it has not identified.
3. Collecting unnecessary information
More data means more:
- Security risk.
- Privacy risk.
- Storage responsibility.
- Compliance responsibility.
4. Keeping PII forever
“Storage is cheap” is not a sufficient privacy strategy.
Retention should be based on applicable requirements and legitimate business needs.
5. Ignoring SaaS suppliers
A company may have strong internal security while sending PII to dozens of external platforms without adequate assessment.
6. Developers have unrestricted production access
Engineering access to production PII should be controlled and justified.
7. No privacy incident process
Organizations sometimes have cybersecurity incident procedures but no process for assessing privacy consequences and notification obligations.
8. Assuming one privacy law applies everywhere
Privacy requirements depend on:
- Jurisdiction.
- Organization.
- Data subjects.
- Processing activities.
- Contracts.
- Industry.
9. Privacy policy does not match actual processing
The website may say one thing while the application actually collects and shares much more information.
10. No evidence
A company may say:
“We take privacy seriously.”
An auditor will typically want objective evidence demonstrating how privacy requirements are implemented.
Practical Startup Implementation Model
A practical startup approach is:
Identify
Identify the personal information you process.
↓
Map
Understand where it comes from, where it goes and who can access it.
↓
Determine
Identify applicable legal, regulatory and contractual requirements.
↓
Protect
Implement appropriate technical and organizational safeguards.
↓
Control
Manage access, suppliers, sharing and processing.
↓
Retain
Define appropriate retention requirements.
↓
Respond
Handle privacy requests and privacy incidents.
↓
Delete
Securely delete or otherwise dispose of information when required.
↓
Review
Periodically review privacy compliance and processing activities.
Policy vs. Process vs. Evidence
| Category | Example |
|---|---|
| Policy | Privacy and Personal Data Protection Policy |
| Policy | Data Classification Policy |
| Process | PII Inventory Process |
| Process | Privacy Request Procedure |
| Process | Data Retention & Deletion Procedure |
| Process | Privacy Incident Response Procedure |
| Process | Supplier Privacy Assessment Procedure |
| Evidence | PII inventory |
| Evidence | Data flow diagram |
| Evidence | Privacy assessment |
| Evidence | DPA |
| Evidence | Access review |
| Evidence | Deletion record |
| Evidence | Privacy request record |
| Evidence | Supplier assessment |
| Evidence | Privacy incident assessment |
Simple rule
Policy defines the organization’s privacy commitment.
Process explains how privacy requirements are implemented.
Evidence demonstrates that the requirements are actually being followed.
Relationship with Other ISO 27001 Controls
A.5.34 is closely connected with several ISO 27001 controls.
| Control | Relationship |
|---|---|
| A.5.1 | Information security policies |
| A.5.12 | Information classification |
| A.5.13 | Information labelling |
| A.5.14 | Information transfer |
| A.5.15 | Access control |
| A.5.18 | Access rights |
| A.5.19–5.22 | Supplier and ICT supply-chain security |
| A.5.23 | Cloud services |
| A.5.24–5.28 | Security incident management |
| A.5.31 | Legal, regulatory and contractual requirements |
| A.5.32 | Intellectual property rights |
| A.5.33 | Protection of records |
| A.5.36 | Compliance with policies and standards |
| A.8.10 | Information deletion |
| A.8.11 | Data masking |
| A.8.12 | Data leakage prevention |
| A.8.15 | Logging |
| A.8.16 | Monitoring activities |
A.5.34 vs. A.5.33
These controls can sometimes be confused.
A.5.33 — Protection of Records
Focuses on protecting records from:
- Loss.
- Destruction.
- Falsification.
- Unauthorized access.
- Unauthorized release.
A.5.34 — Privacy and Protection of PII
Focuses specifically on:
- Personal information.
- Privacy requirements.
- Appropriate processing.
- Applicable privacy obligations.
- Protection of individuals’ information.
Simple distinction
A.5.33 protects important records.
A.5.34 focuses specifically on privacy and PII.
A record can also contain PII, meaning both controls may apply.
Useful Documents for A.5.34
Organizations may create:
- [Insert Draft Document Link] — Privacy and Personal Data Protection Policy
- [Insert Draft Document Link] — PII Inventory Template
- [Insert Draft Document Link] — Personal Data Processing Register
- [Insert Draft Document Link] — Data Flow Mapping Template
- [Insert Draft Document Link] — Privacy Impact Assessment Template
- [Insert Draft Document Link] — Data Retention and Deletion Procedure
- [Insert Draft Document Link] — Privacy Request Handling Procedure
- [Insert Draft Document Link] — Privacy Incident Response Procedure
- [Insert Draft Document Link] — Third-Party Privacy Assessment Checklist
- [Insert Draft Document Link] — Data Processing Agreement Review Checklist
- [Insert Draft Document Link] — PII Access Review Checklist
- [Insert Draft Document Link] — Privacy Compliance Audit Checklist
A.5.34 Audit Readiness Checklist
Before an ISO 27001 audit, ask:
- Have we identified the PII we process?
- Do we know where PII is stored?
- Do we know why each category of PII is processed?
- Have we identified applicable privacy requirements?
- Have we documented important data flows?
- Are access rights to PII controlled?
- Is sensitive PII appropriately protected?
- Have relevant suppliers been identified?
- Are appropriate contractual requirements in place?
- Do we have retention and deletion rules?
- Can we handle applicable individual privacy requests?
- Do we have a privacy incident process?
- Do employees receive appropriate privacy training?
- Are privacy requirements reviewed periodically?
- Can we provide evidence that the controls actually operate?
Questions a Startup Should Ask
Before declaring A.5.34 implemented, ask:
What personal information do we collect?
Why do we collect it?
Where is it stored?
Who can access it?
Which third parties receive it?
Which privacy requirements apply to us?
How long do we retain it?
How do we delete it?
How do we respond to privacy requests?
What happens if the information is exposed?
If these questions can be answered clearly and supported with evidence, the organization has a much stronger foundation for A.5.34.
Startup-Focused Final Takeaway
ISO 27001 Annex A 5.34 is about ensuring that privacy and PII protection are managed as an organized business and security responsibility rather than treated as a statement on a website.
For a startup, the practical journey is:
Identify PII
↓
Map where it goes
↓
Determine applicable requirements
↓
Define the purpose and handling rules
↓
Protect it
↓
Control access and third parties
↓
Manage retention and deletion
↓
Handle privacy requests and incidents
↓
Review compliance
The key question for A.5.34 is:
“Can we demonstrate that we know what personal information we process, why we process it, where it goes, who can access it, how it is protected, how long we retain it, and what privacy requirements apply?”
For startups serving customers across multiple countries, this control becomes especially important because privacy obligations can arise from the organization’s own operations, customer contracts and the jurisdictions in which it operates or processes personal information.