Build for Privacy

Consumers are increasingly taking their business to where their personal information is best cared for. Successful security and risk management leaders need to support their business objectives with "privacy engineering" to gain a competitive advantage and differentiate offerings in crowded markets.

Overview

Key Challenges

• Many organizations struggle to view privacy and security as different goals. Although they share common traits, both disciplines are quite distinct.
• Products and services lacking privacy considerations represent a clear liability to organizations that process personal information.
• Many organizations fail to factor in the risk to individuals' privacy in their business impact assessments.

Recommendations

Security and risk management leaders responsible for privacy management programs should:

• Transform their privacy programs from a forced to an organic change by implementing privacy engineering guidelines.
• Enforce a clear distinction between building for privacy and building for security by addressing the requirements of the individual's privacy rights and expectations at the product design level.
• Demand products that are "built for privacy," rather than repackaged features for trending market demand.

Strategic Planning Assumption

By 2022, 70% of privacy breaches will be directly attributed to a lack of privacy engineering.

Introduction

As privacy regulations mature, they develop rigor and become more detailed in defining stricter requirements and the repercussions that come with violations. These breaches of trust carry financial, reputational and regulatory implications. A recent "Cost of Data Breach Study" found that the average cost for each lost or stolen record containing confidential information was $141 (financial impact). More recently, Facebook shed slightly more than $100 billion in market cap (almost 20% of its total value) for breaching its users' trust following the Cambridge Analytica incident (reputational impact). With regulatory regimes, such as the General Data Protection Regulation (GDPR), imposing hefty fines, the regulatory impact will be added to the final bill.

This sum total puts into alignment the risk to an individual's privacy with the risk to the organization, making the impact of choosing offerings and services that do not adhere to privacy engineering unacceptable.

Analysis

Embrace Privacy Engineering

Privacy engineering is an approach to business process and technology architecture that combines various methodologies in design, deployment and governance. Properly implemented, it yields an end result with:

• Easily accessible functionality to fulfill the Organisation for Economic Co-operation and Development (OECD) eight privacy principles.
• Mitigation against the impact of a breach of personal data by reimagining defense in depth from a privacy-centric vantage point.

The process involves ongoing recalculation and rebalancing of the risk to the individual data owner, while preserving optimum utility for personal data-processing use cases.

Security and risk management (SRM) leaders should assess services for their capacity to provide contextual protection for personal information and factor in the risk to the individual first and foremost. They should avoid contorted messaging that attempts to repurpose existing features and pass them off as privacy.

The best way to parse a set of offerings is to test a solution's capacity to answer these functional questions:

• Do its standard features have the capacity to address the OECD eight privacy principles?
• Does it differentiate personal information from any other type of information, and does it handle this information differently, in line with the risk to the individual data owner.

When looking at solutions already in place, it is equally important to conduct this assessment, understand the limitations and determine how to best remediate.

Practical Examples of Privacy Engineering

Database Design

Most systems use relational databases to store information. These databases are a prime target for any attacker, because they comprise a vast, structured repository that can be easily read and monetized. In one case, more than 560 million login credentials were exposed by a single, unsecured database instance. Even though database encryption has been around for quite a long time, it's rarely used, because it adversely affects performance and search indexing.

SRM leaders should insist — and verify — that application teams adhere to privacy engineering guidelines. The SRM leaders must guide application developers to architect databases that segregate personal information and handle it differently. In this instance, one "core" table would house the main identifiable user data, together with independent references to the other tables. Application architects needn't encrypt the entire database — only the core table — and handle its index in memory. This would render the data worthless to an attacker, because they would be unable to link records to their owners, breaking the chain and substantially reducing the impact a breach would have on the individual data owners.

Data Retention

Organizations that hold personal data should only do so if the purpose for which the data was collected is still valid or fulfills a statutory requirement (OECD Use Limitation Principle); once these conditions expire, so should the information. Simply put, organizations should hold personal information for as short a time as possible to respect the data subject's wishes and reduce the risk to the individual's privacy by limiting exposure.

The challenge comes as solutions are measured for their resilience and their capacity to recover with minimal data loss, not for their capacity to forget.

Solutions that adhere to privacy engineering should maintain records of data validity (e.g., consent purpose or expiration dates) and manage them with the capacity to retain and dispossess. Furthermore, care should be taken to assess whether records are, in fact, deleted from your systems. Many developers merely mark a record as deleted and hide it in the user interface to maintain database consistency (e.g., foreign key constraints that did not take deletion into consideration at the design phase).

Individual data owners provide their personal data for the fulfillment of a purpose. Barring regulatory or legal retention requirements, once that purpose is fulfilled, the data should either be disposed of or anonymized as per a structured data retention policy.

The ultimate goal is to ensure that the individuals' privacy is exposed to as little risk as possible and well below a predefined threshold that's in line with the data's sensitivity.

Privacy Challenges Rarely Have Security-Only Solutions

Organizations often mistake security features, such as access control or certified cryptography, for privacy. Security makes up one component of a varied toolbox of capabilities to address privacy requirements. The ultimate goal is to provide an accessible and functional outcome. This involves the capacity to easily respond to subject rights requests (SRRs), a family of subject rights that includes subject access requests (SARs), update requests and deletion requests. It also includes the capacity to delete personal data once it's no longer needed, without manual intervention or complex processes.

To the detriment of an industry, security has come to be measured by a checklist of features. Great care should be taken to avoid remedying privacy concerns through compliance. Compliance guarantees neither security nor privacy, and it often produces a false sense of security. Successful SRM leaders steer a privacy program aimed at bringing about a transformation in how personal data is handled. This requires that systems be made aware of personal information, its sensitivity and the risks it carries, measured on the impact to the individual data owner, rather than the organization. Simply put, two identical lists (e.g., name and email) would require different handling if one is a list of subscribers to a discount shopping service and the other is a list of HIV-positive individuals in a geographic area.⁶

For the purposes of illustration, consider the right to access (OECD Individual Participation Principle). This affords an individual the right to view his or her personal data held by a third party. To achieve this requirement, the organization will need solutions that provide a wide range of capabilities, including:

• Classification and tagging of personal data, so as to treat distinct types of data differently
• Indexing for the purpose of search across structured and unstructured repositories
• Dynamic masking of personal data pertaining to other individuals found in the response. (Providing access rights to one person should not violate the privacy of another.)
• Logs of processing activities to show historical record keeping and how the data is used.
• Records of backup activity to make a decision on the need to pull data from archives.
• Records of any third-party services that provide supporting functionality and may store additional data, such as a hosted customer service platform for logging support tickets.
• Connectors and APIs to be able to pull information securely from external supporting services.

Few privacy challenges have security-only solutions. SRM leaders should widen their field of vision by looking at the full IT and governance toolbox. Consider maintaining a prioritized privacy risk register, based on the impact to the data subject. Tracking is only part of the challenge — measurement is equally important. Create distinct metrics for privacy by testing the extent to which a solution can adhere to the OECD eight privacy principles. This could be as simple as calculating and benchmarking the time and cost to respond to SRRs.

Privacy Engineering Guidelines

The following guidelines provide SRM leaders who need to adhere to privacy engineering with the foundation required to run a successful privacy program. The list is by no means exhaustive, and will continue to be developed.

Monitor

• Develop solutions that allow assigning structured metadata to records; this will support:
• Classification of data as personal information, which should not interfere with or supersede existing classification schemes; this is meant to enable the system to effectively track user records.
• Expiration dates on personal records to support data minimization and retention policies. Once data expires, a decision can be made to extend expiration (with a valid purpose), anonymize or delete the information.
• Sensitivity scores for personal records to support risk-based decision making.
• Develop and maintain validity matrices that are intended to outline how personal information should be handled. For example, consent tables indicate how individual contact details can be used.
• Maintain independent logs for the processing of personal information (e.g., access, usage and modification). This will support various data subject rights and provide a historical record of the data life cycle to demonstrate due process and due diligence.

Enforce

• Develop processing functions that can use the personal information metadata to vet the processing activity against a validity matrix. This ensures that processing is in line with the purpose for which the information was collected and information has sufficient controls in line with the risk to the individual data owner.
• Ensure that historical data is translated into the new validity matrix model.
• Maintain one master record of personal data and conduct dynamic masking, on the fly and as needed. Creating copies expands the attack surface and exposes the data subject to further privacy risk.
• Conduct data minimization sweeps in which validity is assessed and corrective action is taken, based on the data retention policy.

Communicate

• Maintain a transparent, outward-facing privacy notice; this is the organization's commitment to the data subject.
• Enforce the commitments in the privacy notice through an internal privacy policy that provides guidance to employees and partners on the handling of personal information.
• Secure leadership buy-in in line with the external privacy notice and supported by the internal privacy policy.

Empower

Provide a secure user dashboard where individuals can access and exercise their data subject rights. This provides an interface that includes among its capabilities, enabling individual data owners to:

• View what data is held and enable them to correct it through a structured process
• Understand where data is stored and how it's used
• Understand who has access to this data
• Outline a set of rights and how to invoke them
• Provide contact details for queries and escalations