Privacy protection in asset security

Much of the information organizations protect is personal information: data about customers, employees, patients, students and citizens. Domain 1 covered privacy law and transborder data flows in detail. This lesson looks at privacy from the asset security side: how privacy principles shape the way personal information is collected, classified, handled, retained and destroyed, how privacy by design works in practice, how de-identification fits in, and how privacy impact assessments and data subject requests depend on good asset management. The aim is to see privacy and security as partners: security protects personal information, and privacy decides what personal information the organization should hold in the first place.

Privacy and security are different but linked

Security protects information of all kinds against unauthorized access, change and loss. Privacy concerns the appropriate collection, use, disclosure and retention of personal information, and the rights of the individuals it describes. An organization can have strong security and still violate privacy, for example by collecting data without a lawful purpose, using it in ways people were not told about, or keeping it forever behind excellent controls. Conversely, privacy promises are empty without security, which is why every major privacy law includes a safeguards or security principle. For the CISSP, remember that the asset security practices in this course, such as inventory, classification, handling, retention and destruction, are also the practical machinery of privacy compliance.

Fair information principles

Most privacy laws build on the fair information principles first set out internationally in the OECD Privacy Guidelines of 1980, updated in 2013. Canada's PIPEDA expresses them as ten principles in Schedule 1; the GDPR expresses them as principles in Article 5; and US laws express them in sector-specific and state statutes. The key principles for asset security are accountability, identifying purposes, consent, limiting collection, limiting use, disclosure and retention, accuracy, safeguards, openness, individual access and challenging compliance.

PIPEDA's ten principles are accountability; identifying purposes; consent; limiting collection; limiting use, disclosure and retention; accuracy; safeguards; openness; individual access; and challenging compliance. The safeguards principle requires security safeguards appropriate to the sensitivity of the information, including physical, organizational and technological measures, and requires care in disposal to prevent unauthorized parties from gaining access. Alberta and British Columbia have substantially similar Personal Information Protection Acts, Quebec's private-sector law as amended by Law 25 adds stronger obligations such as privacy impact assessments, privacy by default for technological products and services, and a right to de-indexation, and provincial health laws such as Ontario's Personal Health Information Protection Act govern health information custodians.

The principles translate directly into asset security tasks. Identifying purposes and limiting collection drive data minimization at the collection stage. Limiting retention drives the retention schedule and disposal. Safeguards drive classification, handling and protection methods. Individual access and accuracy depend on knowing where every copy of a person's data is, which depends on the inventory and data maps. Accountability requires named owners and documented decisions.

Privacy by design and by default

Privacy by design, an approach developed in the 1990s by Ann Cavoukian when she was Information and Privacy Commissioner of Ontario, calls for privacy to be built into systems and processes from the start rather than added later. Its seven foundational principles are: proactive not reactive, preventative not remedial; privacy as the default setting; privacy embedded into design; full functionality, positive-sum not zero-sum; end-to-end security across the full life cycle; visibility and transparency; and respect for user privacy, keeping it user-centric. The GDPR made data protection by design and by default a legal obligation in Article 25, and Quebec's Law 25 requires that technological products or services offered to the public have privacy settings that provide the highest level of confidentiality by default.

In practice, privacy by design means asking privacy questions at the same points where lesson 5 asked security questions: in requirements, in design reviews, in procurement and in testing. Does the system need this field? Can it work with a pseudonym? Can the default sharing setting be private? Can data be deleted automatically when the purpose ends? Can access be logged so misuse is detectable? Each yes reduces risk at little cost when designed in, and each no is expensive to fix later.

Privacy impact assessments

A privacy impact assessment (PIA), called a data protection impact assessment (DPIA) under the GDPR, is a structured review of a project or system that handles personal information. It describes the data flows, identifies privacy risks to individuals, and records the measures that reduce those risks. PIAs depend on asset knowledge: you cannot assess risk without knowing what data is collected, where it is stored, who can access it, how long it is kept and who it is shared with.

In Canada, the Treasury Board Directive on Privacy Practices requires federal institutions to conduct PIAs for new or substantially modified programs that use personal information, and the Office of the Privacy Commissioner encourages private organizations to do the same. Quebec's Law 25 makes PIAs mandatory for private organizations for any project to acquire, develop or overhaul an information system or electronic service delivery system involving personal information, and before communicating personal information outside Quebec. Several provincial health and public-sector laws also require them.

A PIA is not just a form. It should happen early enough to change the design, be reviewed by privacy and security specialists, be approved by the accountable owner, and be updated when the system or its use changes. Its findings often become security requirements: encryption of a sensitive field, shorter retention, role-based access, logging, or a decision not to collect an item at all.

De-identification in practice

Lesson 7 introduced pseudonymization and anonymization as protection methods. From a privacy perspective, de-identification is a way to keep the value of data for analytics, research and testing while reducing risk to individuals. It works best when combined with other controls, because re-identification risk depends on who receives the data and what other data they can link it to. A common approach is to match the level of de-identification to the release environment: lightly de-identified data for trusted internal analysts under contract and monitoring, more heavily de-identified data for external researchers under a data-sharing agreement, and aggregate or differentially private statistics for public release.

Data subject requests depend on asset management

Privacy laws give individuals rights over their information. Access rights exist under PIPEDA, the GDPR, HIPAA and state laws; correction rights are widespread; deletion rights exist under the GDPR, Quebec's Law 25 in some circumstances and state laws such as the CCPA; and portability rights exist under the GDPR and some state laws. Responding within the legal deadlines, generally 30 days under PIPEDA and the GDPR (with possible extensions) and 45 days under the CCPA (extendable), requires the organization to find every copy of a person's data across systems, archives, exports and processors. An accurate inventory, data maps and data discovery tools, covered in lessons 1 and 6, are what make this possible.

Privacy-enhancing technologies

Privacy-enhancing technologies (PETs) reduce how much personal information must be exposed to achieve a goal. They include the methods from lesson 7, such as tokenization, pseudonymization, differential privacy and confidential computing, plus techniques such as federated learning, where models are trained on data that stays on devices or in separate organizations, and synthetic data generation. PETs are tools, not exemptions: an organization still needs a lawful purpose, transparency and accountability, but PETs can make a legitimate use far less risky.

Breach response and personal information

When personal information is lost or stolen, privacy and asset security meet again. The classification of the data, the protection method, and the inventory determine how serious the breach is and who must be notified. Encryption with keys that were not compromised often changes the outcome, because many breach notification laws treat properly encrypted data as not having been exposed. Domain 1 covered notification rules in detail; the asset security lesson is that good classification, encryption and inventory before a breach make the response faster, cheaper and less damaging.

Thinking like a manager

When a scenario involves personal information, check the privacy principles before reaching for technology. Is the collection necessary? Is the use consistent with the purpose? Is the retention justified? Has a PIA been done? Only then ask which security controls fit. The best answers often reduce the personal information involved, through minimization, de-identification or shorter retention, rather than adding more controls around data that should not be there. And remember that privacy is part of every owner's accountability, supported by the privacy officer and enforced by the controls custodians operate.

Privacy notices and transparency

Transparency is a privacy principle with direct asset security consequences. Privacy notices tell individuals what personal information is collected, why, who it is shared with, where it is stored and how long it is kept. If the notice says data is kept for two years, the retention schedule and disposal processes must actually deliver that; if it says data stays in Canada or the United States, the inventory and cloud configuration must prove it. Mismatches between what notices promise and what systems do are a frequent basis for regulatory action, including FTC enforcement for deceptive practices and findings by Canadian privacy commissioners. Security and privacy teams should therefore review notices whenever systems, vendors or data flows change, and owners should confirm that their data sets match what the organization has told the public.