Privacy Is Complicated. Information Security Is Complex.

Why Boards, CISOs, CIOs and DPOs Must Stop Treating Them as the Same Problem

By Eckhart Mehler for CISOsCISO — a perspective on cybersecurity leadership, governance and the decisions that determine whether organizations retain control.

There is a recurring misunderstanding in executive discussions about governance, risk and compliance:

“Isn’t information security basically the same as data protection?”

It is not.

They overlap. They depend on each other. They often fail together. But they are not the same discipline, not the same management problem, and not the same leadership challenge.

A useful way to describe the difference is this:

Data protection is often more complicated. Information security is often more complex.

At first glance, this may sound like a semantic distinction. It is not. For boards, CISOs, CIOs, DPOs, compliance leaders and risk owners, the difference matters deeply.

Because if an organization treats a complex security problem as if it were merely a complicated compliance task, it may create documentation without resilience.

And if it treats a complicated privacy problem as if technology alone could solve it, it may build systems that are technically secure but still process personal data unlawfully, unfairly or without sufficient legitimacy.

Both errors are dangerous.

But they are dangerous in different ways.

Complicated Is Not the Same as Complex

A complicated problem has many parts.

It may require expertise, structure, interpretation, coordination and careful execution. It may involve difficult questions, multiple stakeholders and a long decision path. But if the relevant facts are known, the applicable rules are understood, and the right method is followed, a defensible answer can usually be reached.

A complex problem behaves differently.

It contains interactions, dependencies, feedback loops, uncertainty, external pressure and human behavior. Its outcome cannot be fully predicted by analyzing the individual parts separately. Small changes can have disproportionate consequences. Controls may work in one environment and fail in another. The system adapts.

This is why modern organizations can have policies, audits, dashboards, certifications and security tools — and still be surprised by a major incident.

Not necessarily because people were careless.

But because the environment was complex, while the organization managed it as if it were only complicated.

That distinction is essential.

A complicated problem can often be solved by expert analysis.

A complex problem must be governed, observed, adapted and continuously steered.

Why Data Protection Is Often Complicated

Data protection is demanding because it is normative.

It is not primarily about whether an organization can process personal data. It is about whether it is allowed to process personal data — in a specific way, for a specific purpose, under specific conditions, with appropriate safeguards, and for a defined period of time.

The core question is not technical feasibility.

The core question is legitimacy.

A serious privacy assessment may need to answer questions such as:

• What is the purpose of the processing?
• Which legal basis applies?
• Is consent required, or can legitimate interest be used?
• Who is the controller?
• Who is the processor?
• Is there joint controllership?
• Are special categories of personal data involved?
• Is a data protection impact assessment required?
• Are individuals being profiled or monitored?
• Is automated decision-making involved?
• Are data subject rights affected?
• Will data be transferred internationally?
• Which retention period applies?
• Which information obligations must be fulfilled?
• What must be documented?
• Who must be informed?
• Who must approve?

These questions can be difficult. They require legal expertise, organizational understanding, process knowledge and technical literacy.

But in many cases, they are structurally addressable.

The facts can be clarified. The processing purpose can be defined. The legal basis can be assessed. The risks to individuals can be evaluated. Safeguards can be specified. Retention can be determined. Documentation can be created. A decision can be made.

That does not make data protection easy.

It makes it complicated.

The difficulty lies in precision, interpretation, proportionality, accountability and documentation.

In practice, privacy becomes particularly difficult when the organization does not fully understand its own data flows. This is common in large organizations. Personal data moves through HR systems, collaboration platforms, SaaS tools, analytics environments, cloud services, case management systems, identity platforms, ticketing systems and archived file shares.

The privacy question then becomes more than a legal question.

It becomes an organizational discovery exercise.

• What data do we process?
• Where is it stored?
• Who has access?
• For which purpose?
• Under which responsibility?
• For how long?
• In which jurisdiction?
• With which suppliers?
• Under which contracts?
• With which residual risks?

The complication increases when technology, legal reasoning and operational reality do not align.

This is visible in cloud adoption, AI systems, employee monitoring, international data transfers, large-scale analytics, retention conflicts and secondary use of data.

Still, the nature of the challenge remains largely one of structured judgment.

Data protection asks the organization to justify what it does with personal data.

And that justification must be legally, ethically and operationally defensible.

Why Information Security Is Often Complex

Information security starts from another reality.

It is not only about whether something is allowed.

It is about whether the organization can protect what it depends on.

• Confidentiality.
• Integrity.
• Availability.
• Authenticity.
• Traceability.
• Resilience.
• Control.

Information security is broader than privacy because it protects not only personal data, but information, systems, processes, infrastructure, identities, services, business continuity and trust relationships.

• It also operates in an adversarial environment.
• There are attackers.
• There are insiders.
• There are suppliers.
• There are geopolitical pressures.
• There are criminal business models.
• There are misconfigurations.
• There are legacy systems.
• There are unmanaged endpoints.
• There are privileged accounts.
• There are insecure interfaces.
• There are cloud dependencies.
• There are rushed projects.
• There are undocumented exceptions.
• There are risks nobody has formally accepted because nobody has properly seen them.

This is why information security becomes complex.

A seemingly small weakness in identity governance can become a cloud compromise.

A missing log source can become a blind spot in incident response.

A poorly governed SaaS tool can become a data leakage channel.

A procurement shortcut can become a long-term dependency.

A test environment can become a production-level risk.

A local exception can become a global pattern.

An over-permissive collaboration platform can become an uncontrolled information distribution mechanism.

A weak supplier process can become the first step of a supply-chain compromise.

A backup strategy that looks adequate on paper can fail when recovery is tested under real pressure.

Information security is rarely defeated by one missing control alone.

It is defeated by the interaction of missing controls, unclear ownership, technical debt, weak governance, human behavior and active threat actors.

That is complexity.

A privacy assessment may lead to a clear decision.

A security assessment may reveal that the organization does not fully understand its own dependency structure.

That is a different class of problem.

The Core Difference: Legitimacy vs. Control

Data protection asks:

May we process this personal data in this way?

Information security asks:

Can we protect the information, systems, processes and dependencies that make this organization function?

The first question is primarily about legitimacy.

The second is primarily about control.

Both are essential.

But they require different leadership capabilities.

Privacy requires legal clarity, ethical judgment, transparency, proportionality and disciplined processing governance.

Information security requires system understanding, threat awareness, architecture, operational maturity, detection capability, recovery readiness and continuous risk steering.

Privacy can be weakened by vague reasoning.

Security can be weakened by invisible dependencies.

Privacy fails when the organization cannot justify what it does.

Security fails when the organization cannot withstand what happens to it.

This difference becomes especially relevant at board level.

A board can approve a privacy risk if the legal basis, safeguards and residual exposure are clearly presented.

But information security risk is often harder to reduce to a single legal decision. It may depend on architecture, maturity, technical debt, suppliers, local implementation, user behavior, monitoring capability, incident response and recovery options.

Security risk is not only accepted.

It is lived.

Every day.

Across systems, identities, processes, vendors and people.

Why Boards Often Understand Privacy Faster Than Security

Boards often understand privacy risk more quickly than information security risk.

There is a reason for that.

Privacy risk is easier to explain in regulatory terms.

There may be fines, complaints, supervisory authorities, legal obligations, reputational damage and public scrutiny. The language is formal. The consequences are visible. The accountability model is relatively clear.

Information security risk is often less visible until it materializes.

The organization may look stable.

Systems may be available.

Audits may show no major findings.

Dashboards may indicate progress.

Policies may be approved.

Awareness training may be completed.

Certifications may be in place.

And still, the most dangerous risks may sit in places that are not visible at board level:

• an unmanaged privileged account,
• an unmonitored interface,
• a production-like test copy,
• a missing recovery test,
• a supplier dependency,
• a shadow IT process,
• a forgotten legacy system,
• a poorly configured cloud service,
• a local exception that has become standard practice,
• a security-relevant decision made outside security governance.

This is why boards sometimes underestimate information security.

Not because it is less important.

But because its failure modes are often systemic and latent.

Privacy risk often becomes visible through a legal lens.

Security risk often becomes visible through an incident.

By then, the organization may already have lost time, evidence, operational control, trust or strategic room for maneuver.

This is why CISOs must translate security complexity into leadership-relevant risk language.

Not by simplifying reality beyond recognition.

But by showing where the organization is losing control over its dependencies.

The Dangerous Misunderstanding: Reducing Security to Compliance

One of the most dangerous mistakes is to reduce information security to compliance.

This happens when organizations believe that certification, policies, awareness training, audit evidence and formal risk registers are sufficient proof of security.

They are not.

They are important.

But they are not enough.

A certified organization can still have weak identity governance.

A compliant process can still depend on insecure infrastructure.

A documented risk can still be unmanaged in practice.

A policy can exist without technical enforcement.

An audit can confirm formal maturity while missing dangerous operational dependencies.

A risk treatment plan can exist while the actual risk continues unchanged.

A supplier assessment can be completed without meaningful visibility into the supplier’s real security posture.

This is not an argument against compliance.

It is an argument against mistaking compliance for control.

Compliance can create structure.

It can create accountability.

It can create evidence.

It can create repeatability.

It can help an organization define what should happen.

But information security must also verify what actually happens.

Under pressure.

Under attack.

Across borders.

Across suppliers.

Across cloud platforms.

Across exceptions.

Across legacy environments.

Across real human behavior.

The distance between documented intent and operational reality is where many serious security risks live.

A mature CISO does not reject compliance.

A mature CISO makes sure that compliance does not become a substitute for security.

The Reverse Error: Reducing Privacy to Security

There is also a reverse mistake.

Some organizations reduce privacy to information security.

They assume that if personal data is encrypted, access-controlled, logged and monitored, the privacy problem is solved.

It is not.

A system can be technically secure and still process personal data without a valid legal basis.

A system can be well protected and still violate purpose limitation.

A monitoring solution can be technically effective and still be disproportionate.

A data lake can have strong access controls and still contain data that should never have been collected.

An AI system can be secured against external attack and still create unacceptable privacy risks.

A retention mechanism can be technically robust and still preserve data longer than justified.

Security protects processing.

It does not automatically legitimize processing.

This distinction is essential.

Security can protect unlawful processing.

Privacy can document insecure processing.

Both are failures.

And both can create serious organizational risk.

Where Privacy and Security Meet

The relationship between data protection and information security is not hierarchical.

It is interdependent.

Privacy needs security because personal data cannot be protected by legal reasoning alone.

Access control matters.

Logging matters.

Encryption matters.

Deletion matters.

Data minimization must be implemented technically.

Retention rules must be enforceable.

Third-party access must be governed.

Cloud configurations must reflect privacy commitments.

Security needs privacy because not every technically possible control is automatically acceptable.

Monitoring must respect proportionality.

Logging must be purposeful.

Employee data must be handled carefully.

AI-enabled detection must be assessed.

Insider-risk programs need governance.

Data analytics must have boundaries.

Identity governance must avoid unnecessary exposure of personal information.

The best organizations do not ask whether privacy or security “owns” a topic.

They ask better questions:

• Which part of the decision requires legal legitimacy?
• Which part requires technical assurance?
• Which part requires organizational accountability?
• Which part requires risk acceptance?
• Which part requires board-level visibility?
• Which part requires continuous monitoring?

This is where mature governance begins.

Not in ownership battles.

But in the ability to connect different forms of risk into one coherent decision.

The AI Example: Why the Distinction Matters More Than Ever

Artificial intelligence makes the difference between privacy and security even clearer.

A privacy assessment of an AI system may ask:

• What data is used for training, prompting, retrieval or inference?
• Is personal data involved?
• Are special categories of personal data processed?
• Is the processing transparent?
• Is there a valid legal basis?
• Are individuals affected by outputs?
• Is automated decision-making involved?
• Can data be deleted?
• Are third-party providers involved?
• Are international transfers taking place?
• Can the processing be explained?
• Are retention periods defined?

These questions are necessary.

But they are not sufficient.

An information security assessment will ask different questions:

• Can prompts leak confidential information?
• Can the model be manipulated?
• Can retrieval systems expose sensitive documents?
• Can agents perform unintended actions?
• Can excessive permissions turn an AI assistant into a privilege escalation path?
• Can outputs trigger operational or compliance errors?
• Are logs available?
• Can misuse be detected?
• Can the organization revoke access quickly?
• Can it contain the damage?
• Can it recover?
• Can it prove what happened?

AI does not merely process data.

It changes how decisions, access, automation and trust are distributed across the organization.

That is why AI governance cannot be owned by one function alone.

A DPO may understand the legitimacy of processing.

A CISO may understand the attack surface.

A CIO may understand the architecture.

A compliance function may understand accountability obligations.

A business owner may understand the intended value.

But none of them alone understands the full risk.

The more AI becomes embedded into business processes, the less useful siloed assessments become.

AI risk is not only a privacy issue.

It is not only a security issue.

It is not only an ethical issue.

It is a governance issue.

And governance must be strong enough to connect all of them.

What Mature Organizations Do Differently

Mature organizations do not merge privacy and information security into one blurred responsibility.

They create clear interfaces.

They define decision rights.

They establish joint review points.

They align risk language.

They ensure that privacy assessments include real security evidence.

They ensure that security architectures reflect privacy obligations.

They involve the DPO early.

They involve the CISO early.

They involve architecture, procurement, legal, compliance and operations before decisions become irreversible.

They do not wait until the system is live.

They do not wait until procurement is completed.

They do not wait until the exception has become business-critical.

They do not wait until the audit asks for evidence.

They do not wait until an incident reveals what should have been visible earlier.

In mature organizations, privacy and information security are connected to real decision-making.

Not only to documentation.

Not only to audit preparation.

Not only to policy maintenance.

But to architecture, procurement, cloud strategy, AI adoption, identity governance, supplier management, incident response and business resilience.

This is one of the defining differences between formal maturity and real maturity.

Formal maturity asks:

Do we have the required documents?

Real maturity asks:

Do our decisions, controls and behaviors hold under real conditions?

A Practical CISO View

From a CISO perspective, I would frame the distinction like this:

Data protection is often harder to decide.

Because the decision may require legal interpretation, proportionality, ethical judgment, jurisdictional awareness and careful documentation.

Information security is often harder to control.

Because the control environment is dynamic, distributed, technical, human, geopolitical and adversarial.

A DPO may ask:

Can we justify this processing?

A CISO may ask:

Can we still defend, detect, respond and recover when this processing becomes part of a real attack surface?

Both questions are valid.

Both are necessary.

But neither replaces the other.

The organization needs both perspectives before major decisions are made — especially in cloud, AI, outsourcing, identity, data platforms, collaboration environments and critical business processes.

The more international, digital and interconnected an organization becomes, the more dangerous it is to separate legitimacy from control.

A lawful process that cannot be secured is a risk.

A secure process that cannot be justified is also a risk.

Leadership must be able to see both.

Why This Distinction Matters for ISO 27001 Organizations

For organizations operating an information security management system, especially those certified against ISO/IEC 27001, this distinction is highly relevant.

An ISMS provides a management framework for information security. It creates structure for scope, risk assessment, risk treatment, controls, monitoring, internal audits, management review and continual improvement.

But an ISMS is not automatically a privacy management system.

And a privacy program is not automatically an ISMS.

There are strong intersections: risk management, supplier control, access management, incident response, asset management, logging, retention, awareness, governance and documentation.

But the objectives are not identical.

Privacy focuses on the rights and freedoms of individuals in relation to personal data processing.

Information security focuses on protecting information and related assets against threats to confidentiality, integrity and availability.

In practice, mature organizations use the ISMS as a powerful governance engine — but not as a replacement for privacy governance.

They connect both systems where they overlap.

They keep the decision logic distinct where necessary.

They avoid duplicate processes.

They avoid contradictory assessments.

They avoid the dangerous assumption that one certification proves everything.

An ISO 27001 certificate can support privacy assurance.

It does not replace privacy accountability.

A privacy assessment can support security requirements.

It does not prove security resilience.

That distinction should be clear in governance documents, risk reports, procurement processes, AI approvals, cloud decisions and board communication.

What Executives Should Ask

For executives, the most useful question is not:

Is privacy or information security more important?

That question leads nowhere.

The better question is:

Does our organization understand the difference well enough to manage both properly?

A board or executive committee should ask:

Where do privacy and security decisions intersect in our organization?

Are the DPO and CISO involved early enough in strategic projects?

Do privacy assessments include meaningful security input?

Do security architectures reflect privacy requirements?

Are AI initiatives reviewed from both perspectives?

Do procurement processes identify both privacy and security risks?

Are supplier risks assessed beyond contractual language?

Are retention and deletion requirements technically enforceable?

Do we know where production-like data is used outside production?

Are access rights aligned with purpose limitation and need-to-know?

Can we detect misuse of sensitive information?

Can we recover from security incidents affecting personal data?

Are privacy incidents and security incidents governed coherently?

Do our dashboards show real risk, or mainly formal completion?

These questions are not academic.

They determine whether governance works in reality.

The Leadership Lesson

The leadership lesson is simple:

Privacy without security becomes a promise the organization may not be able to keep.

Security without privacy becomes control without legitimacy.

The future will punish both weaknesses.

Regulators will not accept privacy programs that ignore technical reality.

Attackers will not care that security weaknesses were documented in a compliant process.

Customers, partners and employees will not separate privacy and security when trust is lost.

They will simply ask:

Why did the organization not understand the risk?

This is the point where executive leadership becomes essential.

Because privacy and information security cannot be solved by specialists alone.

Specialists can assess.

Specialists can advise.

Specialists can design controls.

Specialists can document decisions.

But leadership determines whether the organization gives these disciplines the authority, timing, resources and visibility they need.

A DPO involved too late becomes a documentation function.

A CISO involved too late becomes a remediation function.

Both should be governance functions.

Both should shape decisions before risks become embedded.

Final Thought

Data protection is the discipline that helps an organization justify the processing of personal data.

Information security is the discipline that helps an organization protect the systems, information and dependencies that make that processing possible.

One is often complicated.

The other is often complex.

Both are strategic.

Both require leadership.

Both must be connected to real decisions.

And both must be strong enough to survive contact with reality.

Because trust is not created by documentation alone.

Trust is created when legal legitimacy, technical protection and organizational accountability work together — under real conditions, not only on paper.

Publication Note & Disclaimer

It reflects my personal professional perspective and does not represent the official policy or position of my employer. Drafting and editorial refinement may have been supported by commercially available AI-assisted tools. The analysis, conclusions and final curation are entirely my own.

For information regarding image credits, copyrights, trademarks and other intellectual property rights, please refer to the Imprint.