A.5.34 through A.5.37 — Privacy Policies Review and Documented Procedures

A.5.34 through A.5.37 — Privacy Policies Review and Documented Procedures

Understanding ISO 27001's Privacy Control Framework

Controls A.5.34 through A.5.37 represent some of the most misunderstood requirements in ISO 27001:2022. I've seen organizations treat these as separate checkbox exercises—privacy team drafts A.5.34, internal audit owns A.5.35, compliance handles A.5.36, operations writes A.5.37 procedures. The result? Fragmented documentation that creates audit failures and genuine security gaps.

These four controls form an interconnected privacy governance framework. Control 5.34 (Privacy and protection of PII) establishes your privacy obligations. Control 5.35 (Independent review of information security) provides oversight mechanisms that directly impact privacy assurance. Control 5.36 (Compliance with policies, rules and standards) ensures adherence to privacy frameworks. Control 5.37 (Documented operating procedures) translates privacy policies into operational reality.

The fatal flaw I observe repeatedly: organizations implement these controls in silos. When I audit the interconnections—asking how privacy impact assessments feed into risk treatment under Clause 6.1.3, or how incident response procedures under Control 5.26 handle privacy breaches—the framework collapses.

Control 5.34: Privacy and Protection of PII—Beyond Legal Compliance

If your Control 5.34 implementation consists primarily of a privacy notice copied from a template, you've fundamentally misunderstood the requirement. This control demands that privacy and PII protection be addressed "in accordance with applicable legislation, regulations and contractual requirements." That final phrase—contractual requirements—is where most organizations stumble.

During a recent audit of a SaaS provider, I found pristine GDPR documentation. They'd invested in Article 30 records of processing, conducted data protection impact assessments, established lawful bases—comprehensive regulatory compliance. Then I reviewed their customer data processing addendums. Customers had negotiated 24-hour breach notification requirements (not the regulatory 72 hours), specific geographic data residency restrictions, and quarterly privacy audit rights. Their operational procedures supported none of these contractual commitments.

Effective Control 5.34 implementation requires four foundational elements:

  • Comprehensive privacy obligation inventory—regulatory, contractual, and voluntary commitments. This means actually reading customer agreements, vendor contracts, and partnership terms. Cross-reference these with your Statement of Applicability to ensure privacy risks are addressed in your risk treatment plans under Clause 6.1.3.
  • Privacy impact assessments integrated with ISMS risk assessment—Privacy risks are information security risks. If your risk register under Clause 6.1.2 lacks privacy scenarios, you have a gap. Reference ISO/IEC 29134 for privacy impact assessment methodology that complements your Clause 6.1 risk management.
  • Data classification framework distinguishing PII categories—Not all personal data carries equal risk. Biometric data requires different protections than contact information. Your asset inventory under Control 5.9 should reflect these distinctions.
  • Clear privacy governance integrated with organizational context—Who owns privacy decisions? Who responds to data subject requests? Who approves new processing activities? These roles must align with your ISMS organizational structure defined in Clauses 4.1 and 4.2.

For cloud service scenarios, reference ISO/IEC 27018:2025 for specific PII processor requirements. If you're processing health data, consider ISO/IEC 27799 for health informatics security guidance. The key is ensuring your Control 5.34 framework addresses your specific processing context, not generic privacy compliance.

Control 5.35: Independent Review—The Most Misunderstood Control

Independent review of information security consistently trips up organizations during audit. The confusion stems from misunderstanding what "independent" actually means. It's not about external auditors—it's about objectivity. The person reviewing a control cannot be the same person implementing it.

I audited a mid-sized manufacturer where the IT manager had documented their backup procedures under Control 8.13, conducted the backup testing, and then "independently" reviewed the backup control effectiveness. That's not independence—that's confirmation bias with documentation.

Effective independence means:

  • Functional separation—If Operations implements access controls under Control 5.15, then IT Security or Internal Audit reviews effectiveness, not Operations.
  • Reporting independence—Review findings must reach management levels that can authorize corrective action. A supervisor reviewing their direct report's work doesn't meet this threshold.
  • Competence independence—Reviewers must understand what they're evaluating. Your finance manager reviewing cryptographic key management under Control 8.24 lacks technical competence for meaningful review.

For smaller organizations, consider peer review arrangements with other departments, external consultants for technical areas, or management-level review for critical controls. Document your independence rationale—auditors will examine this closely.

Tip: When designing review schedules, align with your management review cycle under Clause 9.3. Independent reviews should provide input for management review decisions.

Control 5.36: Compliance Management That Actually Works

Control 5.36 requires compliance with policies, rules, and standards for information security. This sounds straightforward until you realize it applies to internal policies, regulatory requirements, contractual obligations, and industry standards—all simultaneously.

The compliance failure pattern I see most often: organizations track regulatory compliance separately from ISMS compliance. They'll have GDPR compliance matrices, PCI DSS validation reports, and SOX controls documentation—but none of this integrates with their ISO 27001 risk treatment or control monitoring.

Effective Control 5.36 implementation requires:

  • Unified compliance framework—Map all applicable requirements to specific controls. If you're subject to PCI DSS, show how requirements 1.1 through 12.11 map to specific Annex A controls. Reference ISO/IEC 27006 for accreditation requirements if seeking certification.
  • Regular compliance assessment—Beyond annual audits, establish ongoing monitoring that feeds into your continual improvement under Clause 10. Non-conformities identified in compliance assessments should trigger corrective action under Clause 10.1.
  • Clear escalation procedures—When compliance gaps are identified, who acts? How quickly? What constitutes acceptable remediation? These decisions need clear authority and timeline definitions.
  • Evidence management—Compliance isn't just meeting requirements—it's proving you meet requirements. Establish systematic evidence collection that supports both internal reviews and external audits.

Control 5.37: Operating Procedures That Enable Security

Documented operating procedures under Control 5.37 should specify exactly how security-critical activities get performed consistently. The control explicitly lists required procedure elements: responsible individuals, secure system configuration, information processing and handling, backup and resilience, error handling, and escalation contacts.

The most common failure I observe: procedures that describe what should happen, not how to make it happen. I reviewed incident response procedures at a logistics company that beautifully described incident classification matrices and notification timelines. But when a ransomware incident occurred, staff couldn't execute the procedures because they lacked specific technical steps, decision trees for complex scenarios, and current contact information for external specialists.

Effective operating procedures must include:

  • Specific role assignments—Not "IT Department" but "Network Administrator or designated alternate." Include backup assignments for critical procedures.
  • Step-by-step technical instructions—Screenshots, command examples, decision points. Procedures should enable someone with appropriate background knowledge to execute consistently.
  • Exception handling—What happens when normal procedures fail? When systems are unavailable? When key personnel are unavailable? Reference Control 8.18 for utility program restrictions during emergency procedures.
  • Integration points—How do procedures connect to monitoring activities under Control 8.16? To backup procedures under Control 8.13? To incident response under Control 5.26?

Reference the specific operational domains from the control framework: asset management, physical security, system and network security, application security, secure configuration, identity and access management, threat and vulnerability management, continuity, and information security event management.

What the Auditor Looks For

During certification or surveillance audits, I examine these four controls as an integrated system. Here's what I'm looking for:

For Control 5.34 (Privacy and PII protection):

  • Complete inventory of personal data processing activities with legal bases documented
  • Privacy impact assessments that connect to ISMS risk assessment methodology
  • Evidence of privacy by design in new system implementations
  • Data subject request handling procedures with documented response times
  • Cross-border data transfer mechanisms properly documented and implemented

For Control 5.35 (Independent review):

  • Review schedules that cover all implemented controls within defined timeframes
  • Evidence of reviewer independence and competence
  • Review findings that result in corrective action when gaps are identified
  • Management response to significant review findings
  • Review results feeding into management review under Clause 9.3

For Control 5.36 (Compliance):

  • Current compliance obligation register with responsibility assignments
  • Regular compliance assessments with documented results
  • Corrective action tracking for compliance gaps
  • Integration between compliance monitoring and risk treatment

For Control 5.37 (Operating procedures):

  • Procedures that enable consistent execution by qualified personnel
  • Current contact information and escalation paths
  • Procedure version control and change management
  • Evidence that procedures are actually followed during operations
  • Regular procedure testing and updates based on lessons learned

Common Implementation Mistakes

The most significant error I encounter: treating these controls as documentation exercises rather than operational requirements. Organizations produce beautiful policies and procedures that nobody follows during actual operations. During one audit, I found comprehensive incident response procedures that hadn't been updated since a major cloud migration eighteen months earlier. When an actual security incident occurred, staff improvised rather than following outdated procedures.

Another frequent mistake involves assuming privacy obligations are static. I audited a healthcare technology company that had implemented robust privacy controls for their initial product—a patient portal. When they launched a mobile health app with different data flows and third-party integrations, they never updated their privacy impact assessments or operating procedures. The original Control 5.34 implementation became obsolete.

Finally, organizations often implement independent review as a formality rather than a meaningful control. Having someone sign off on review documentation without examining actual implementation provides zero assurance value and creates false confidence in control effectiveness.

Making the Framework Work

These four controls succeed when they're implemented as an integrated governance framework rather than isolated requirements. Your privacy policies under Control 5.34 should drive risk assessment under Clause 6.1.2. Independent reviews under Control 5.35 should validate both privacy and security control effectiveness. Compliance monitoring under Control 5.36 should detect gaps before they become incidents. Operating procedures under Control 5.37 should enable consistent execution of privacy and security requirements.

For organizations seeking certification, demonstrate these interconnections during audit interviews. Show how privacy risks inform control selection, how review findings drive improvement actions, how compliance gaps trigger risk reassessment, and how operational procedures enable policy objectives.

The investment in proper implementation pays dividends beyond audit compliance. When privacy controls integrate with information security management, you create operational resilience that protects both business operations and stakeholder trust.

Ready to strengthen your privacy control framework? For detailed implementation guidance and practical templates, visit our ISO 27001 Info Hub or schedule a consultation to review your current approach against auditor expectations.

Need personalized guidance? Reach our team at ix@isegrim-x.com.


Related Articles

Read more

ISO 27001 and Zero Trust Architecture — Modern Security Meets Compliance

ISO 27001 and Zero Trust Architecture — Modern Security Meets Compliance

Executive Summary: * Architecture-Documentation Alignment: Zero Trust implementations fail audit when security architecture shifts to identity-centric models but ISMS documentation still describes perimeter-based controls * Multi-Framework Convergence: Zero Trust principles naturally align with ISO 27001's risk-based approach and map directly to NIST CSF, CMMC, and TISAX requirements—creating implementation synergies