Risk-Reducing Strategies

What risk-reducing strategies do

Risk-reducing strategies are not a single technology choice, but a design layer that narrows privacy exposure before implementation begins. They influence whether the eventual solution relies on data minimisation, separation, transparency, accountability, or a combination of those controls.

In practice, this means the strategy is chosen at the problem-definition stage, when teams are still deciding what data must exist at all, who needs access, and which privacy-enhancing technologies would be proportionate.

How they shape privacy-enhancing technology choices

Risk-reducing strategies sit upstream of PET selection. A use case that already limits collection, separates sensitive fields, or reduces linkability may need a lighter control stack than one that centralises rich data and then tries to compensate later.

That distinction matters because PETs are not interchangeable. Some are strongest when the data can be transformed before use, while others are better when governance and accountability need to be improved around processing that still has to happen. The strategy therefore helps determine whether the right answer is technical, organisational, or both.

Useful examples include minimising identifiers, segregating datasets, limiting retention, using transparency to make processing understandable, and assigning accountability so privacy obligations have an owner. The NIST Privacy Framework is a useful reference point for thinking about data governance and privacy risk management as part of that design process.

Common design patterns

Most risk-reducing strategies fall into two broad patterns. The first changes the data itself, for example by collecting less, separating what is stored, or reducing the ability to link records across contexts. The second changes the operating model, for example by clarifying disclosures, ownership, review, and decision accountability.

These patterns are often combined. A design may reduce exposure through minimisation while also using governance controls to ensure the remaining processing is visible, justified, and reviewable. The value of the strategy is that it lowers the privacy burden before a system is forced to rely on compensating controls alone.

This is one reason privacy design is often treated as a portfolio of controls rather than a single safeguard. The EU General Data Protection Regulation (GDPR) is relevant here because data protection by design and security of processing both reinforce the idea that privacy should be shaped early, not patched in after deployment.

Why the term matters in privacy governance

Risk-reducing strategies are important because they create the conditions for proportionate privacy engineering. If the design already suppresses unnecessary exposure, the organisation is less dependent on downstream controls to carry all of the burden.

They also create clearer accountability. Teams can explain why a particular design was selected, what exposure it removes, and what residual privacy trade-offs remain. That makes the strategy useful not only for engineers, but also for privacy, legal, and governance stakeholders who need to assess whether the final design is defensible.

For broader governance and privacy-risk management, the NIST Privacy Framework and the GDPR both reinforce the same practical lesson: reduce exposure at the source wherever possible, then use controls to manage what cannot be eliminated.

Related resources from NHI Mgmt Group

• What is the difference between rotating service account credentials and reducing service account risk?
• What is the difference between reducing identity risk and eliminating it?
• Why do cloud migrations often increase IAM risk instead of reducing it?
• How do teams know whether ephemeral credentials are actually reducing risk?