ISO 27701: connect privacy management and security

Privacy management works best when processing decisions, safeguards, rights handling, and supplier responsibilities fit together. ISO/IEC 27701 provides a management-system approach for that work: a privacy information management system, or PIMS.

For a CTO, the challenge is connecting documented obligations to system behavior. A retention policy must become a deletion process; a processor commitment must constrain access and reuse; a privacy review must influence releases. Security controls support these outcomes, but cannot determine whether processing is justified.

Choose the correct edition and relationship to your ISMS

ISO/IEC 27701:2025 is the second edition and establishes PIMS requirements as a standalone standard. The older 2019 edition was an extension to ISO 27001 and ISO 27002. Do not build a new implementation around the assumption that ISO 27001 certification is always a prerequisite. Confirm the applicable edition and transition arrangements with your certification body.

An existing ISO 27001 ISMS remains useful. Governance, risk processes, document control, internal audits, and management review can support both systems. ISO 27002 provides information-security control guidance.

Keep the objectives distinct. Security examines confidentiality, integrity, and availability. Privacy also examines purposes, proportionality, transparency, and consequences for individuals. An encrypted database can still contain unnecessarily collected information. Reusing security evidence is sensible; treating it as proof of privacy compliance is not.

Define scope through processing, not just infrastructure

Start with the services and activities covered by the PIMS. Include supporting systems, teams, suppliers, and interfaces. A boundary such as “production cloud environment” is insufficient if customer support exports personal data into a separate ticketing system.

For each activity, document:

• Purpose, personal-data categories, and affected groups of individuals.
• Controller or processor role, including activities where roles differ.
• Collection sources, recipients, storage locations, and transfer routes.
• Retention rules, deletion behavior, owners, and applicable obligations.

Roles depend on the processing activity, not simply the company's identity. A software provider may process customer-uploaded data under client instructions while acting as controller for its own billing records. These activities need different decision paths.

Assign engineering, product, privacy, procurement, and operational responsibilities explicitly. Where a DPO is required or appointed, preserve their independent advisory and monitoring role rather than making them responsible for choosing processing purposes. The GDPR provides the relevant controller, processor, and DPO obligations.

Assess privacy risks alongside security risks

Use the processing inventory to identify harms to individuals as well as organizational exposure. Unauthorized access matters, but so do excessive collection, unexpected reuse, inaccurate records, inaccessible rights procedures, and retention beyond an established need.

A practical assessment should connect each risk to an activity, consequence, existing safeguard, treatment, accountable owner, and review trigger. Record why the remaining risk is accepted or why further work is required.

Consider a reporting feature that exports employee performance data. Authentication and access logging address security concerns. Privacy analysis must also consider whether the export includes unnecessary fields, exposes sensitive inferences, or enables uses inconsistent with the stated purpose.

A PIMS assessment can support legal assessment work, but does not automatically satisfy every jurisdiction's requirements. Under GDPR Article 35, processing likely to result in high risk requires a data protection impact assessment. Evaluate that threshold separately and retain the decision and any required assessment.

Translate obligations into testable controls

Avoid a privacy policy that engineering cannot implement. For each obligation, specify the expected system behavior and evidence demonstrating it. The following are practical implementation examples, not a universal mandatory control set.

Encryption, least privilege, logging, and recovery remain important shared safeguards. Select measures according to risk: GDPR Article 32 does not impose blanket encryption in every situation. Document key access, recovery, and deletion limitations where they affect privacy outcomes. See encryption and key management for implementation considerations.

Build operating procedures that survive real cases

Rights handling needs an intake route, ownership, proportionate identity verification, system searches, third-party review, and secure delivery. Under GDPR, responses are normally due within one month; permitted extensions require notice within that first month. Keep case records that explain decisions, not merely closed-ticket counts. A subject access workflow should cover manual systems and supplier assistance too.

Incident handling must distinguish technical containment from privacy notification decisions. Under GDPR, processors notify controllers without undue delay. Controllers assess supervisory notification without undue delay and, where feasible, within 72 hours after awareness, unless the breach is unlikely to risk individuals' rights and freedoms. Record non-notification reasoning and assess whether high risk requires communication to individuals.

Supplier procedures should examine instructions, subprocessors, assistance with requests and incidents, return or deletion, and evidence access. Where GDPR applies, Article 28 contracts have specific required elements. A supplier certificate is supporting assurance, not a replacement for those terms.

International transfers require a separate legal assessment. ISO 27701 certification does not authorize them or neutralize surveillance risks. Document the applicable mechanism, assess its conditions, and implement supplementary measures where needed. Data location alone does not establish compliance.

Worked example: a customer-support service

Assume, illustratively, that a SaaS provider processes customer support messages under customer instructions and controls its own account-contact records. Both activities use the same support platform.

The team maps message content, attachments, account identifiers, supplier access, and export destinations. It discovers that a debugging export copies complete messages into an engineering workspace with longer retention.

The treatment is specific: replace full-message exports with minimized diagnostic fields, restrict exceptional access, apply an approved retention period, and record who authorizes exceptions. Test that routine exports omit message bodies and that expired diagnostic records are removed.

The evidence package contains the processing record, role assessment, supplier terms, risk decision, configuration, test results, and approval history. The shared access-control review supports both security and privacy, while the export-purpose decision remains privacy-specific.

Prepare for certification with operational evidence

Certification is performed by an independent certification body, not ISO. Before scheduling assessment, confirm the scope, edition, audit approach, and evidence expectations. A typical initial certification process includes readiness and documentation review followed by assessment of implementation; confirm arrangements with the selected body.

Perform an internal audit against the applicable requirements and your own procedures. Sample processing activities, rights cases, supplier decisions, retention execution, and product changes. Separate a missing document from a control that exists but fails in operation.

Management review should consider findings, unresolved risks, changes, performance, and resources. Corrective actions need owners, completion evidence, and effectiveness checks. Certification can provide assurance about the scoped management system, but does not establish GDPR compliance, create a legal basis, or cover activities outside that scope.

Start with one traceable processing activity

Choose one activity, follow its data through connected systems and suppliers, and link each material obligation to an owner, safeguard, and decision history. Review it after relevant changes rather than waiting for the next audit.

Secani supports this evidence workflow by connecting requirements, controls, systems, evidence, and review decisions. Teams can retain shared ISMS evidence alongside privacy-specific decisions, turn gaps into assigned tasks, and preserve human approval of AI-assisted suggestions. The first useful deliverable is a reviewed chain from processing purpose to implemented safeguard and supporting evidence.