Handling PII and Publicly Available Information

Why This Topic Matters
Personally Identifiable Information (PII) is one of the most heavily regulated and most frequently breached categories of data. In the CSSLP Secure Software Requirements domain, (ISC)² expects you to understand that privacy is not an afterthought bolted on during testing or deployment; it is a requirement that must be captured, classified, and traced from the very beginning of the Software Development Life Cycle (SDLC). Mishandling PII leads to regulatory fines (GDPR, CCPA/CPRA, HIPAA, GLBA, COPPA, PIPEDA), lawsuits, reputational damage, and loss of customer trust. Equally important, and often overlooked, is the handling of publicly available information. Data that is individually harmless can become dangerous when aggregated, correlated, or combined with other data sets, enabling re-identification, social engineering, and targeted attacks. Exam questions in this area test whether you can distinguish between data types, apply the correct protective requirements, and recognize that "public" does not mean "free of security obligations."

What Is PII?
PII is any information that can be used, alone or in combination with other data, to identify, contact, or locate a specific individual. It is commonly divided into two groups:
• Direct identifiers – full name, Social Security Number (SSN) or national ID, passport number, driver's license number, biometric records, email address, account numbers, precise geolocation.
• Indirect (quasi-) identifiers – date of birth, ZIP/postal code, gender, job title, race, religion, education, IP address, device identifiers. These may not identify someone on their own, but linked together they frequently can (the classic study showing that ZIP code + birth date + gender uniquely identifies the majority of the U.S. population).

Related categories you should recognize:
• Sensitive PII – data whose exposure causes significant harm: SSN, financial account data, health records, biometrics, sexual orientation, criminal history. Requires stronger controls than general PII.
• PHI (Protected Health Information) – health data governed by HIPAA in the U.S.
• Cardholder data – governed by PCI DSS; PAN, expiration date, CVV (CVV must never be stored).
• Special category / sensitive personal data – the GDPR term for racial or ethnic origin, political opinions, religious beliefs, genetic data, health data, etc.

What Is Publicly Available Information?
Publicly available information is data that is lawfully accessible to the general public: content on public websites, social media profiles set to public, public records (court filings, property records, business registrations), published directories, press releases, and open government data sets. Key points for the exam:
• Public availability does not remove the data from the definition of PII; a name on a public website is still PII.
• Regulations treat it differently in some cases (e.g., CCPA excludes certain lawfully made-available government records from its definition of personal information), but the organization's own privacy policy, contractual obligations, and ethical standards still apply.
• The aggregation or mosaic problem: combining multiple pieces of public data can create a sensitive profile (home address + work schedule + children's school) that no single source revealed. Software that scrapes, correlates, or enriches public data must treat the result as potentially sensitive.
• Publicly available information about an organization (job postings naming technologies, employee LinkedIn profiles, DNS records, metadata in published documents) fuels reconnaissance and social engineering. Secure requirements should limit unnecessary information disclosure by the application itself (verbose error messages, version banners, comments in HTML, metadata in exported files).

How It Works: Capturing Privacy Requirements in the SDLC

1. Data discovery and classification
The first requirements activity is to identify every data element the software will collect, process, store, or transmit, and classify it (e.g., Public, Internal, Confidential, Restricted/Sensitive PII). Classification drives every downstream control: encryption strength, access control, logging, retention, and disposal. A data inventory or data map (also called a record of processing activities under GDPR) is the primary artifact.

2. Privacy Impact Assessment (PIA) / Data Protection Impact Assessment (DPIA)
A PIA is performed early to identify privacy risks and determine required mitigations. GDPR mandates a DPIA when processing is likely to result in high risk to individuals (large-scale processing of special category data, systematic monitoring, profiling). The output becomes a set of traceable requirements.

3. Apply the Fair Information Practice Principles (FIPPs) and Privacy by Design
These principles translate directly into functional and non-functional requirements:
• Notice/Transparency – users are told what is collected and why (privacy notice, consent screens).
• Choice/Consent – opt-in for sensitive data; ability to withdraw consent.
• Purpose limitation – data used only for the stated purpose.
• Data minimization – collect only what is necessary. This is the single most powerful privacy control: data you never collect cannot be breached.
• Accuracy and integrity – mechanisms for users to view and correct their data.
• Storage limitation / retention – define retention periods and secure deletion; "keep forever" is a requirements failure.
• Security safeguards – confidentiality, integrity, and availability controls proportional to classification.
• Individual participation / data subject rights – access, rectification, erasure (right to be forgotten), portability, objection.
• Accountability – audit trails, defined roles (data controller vs. data processor), and documentation.

4. Technical requirements for protecting PII
• Encryption at rest and in transit using approved algorithms (AES-256, TLS 1.2+); key management requirements.
• Tokenization – replacing a sensitive value with a non-sensitive token; the mapping is stored in a secure vault. Common for payment data.
• Masking / redaction – displaying only partial values (last four digits of SSN or card) in UIs, logs, and reports.
• Anonymization – irreversibly removing identifiers so the data is no longer personal data (truly anonymized data generally falls outside GDPR). Techniques include generalization, suppression, k-anonymity, differential privacy.
• Pseudonymization – replacing identifiers with pseudonyms while keeping a separate key that allows re-identification. Still personal data under GDPR, but a recognized risk-reduction measure.
• Access control and least privilege – role-based access, separation of duties, need-to-know for PII fields; field-level permissions.
• Logging requirements – log access to PII for accountability, but never log the PII itself in plaintext (a frequent exam trap).
• Secure disposal – cryptographic erasure, overwriting, and defined procedures for backups and test environments.
• Test data – production PII must not be copied into development or test environments without masking or synthetic data generation.
• Data residency and cross-border transfer – requirements for where data may be stored and legal mechanisms (standard contractual clauses, adequacy decisions) for transfers.
• Breach notification – the system must support detection and reporting within regulatory timelines (e.g., 72 hours under GDPR).

5. Requirements for handling publicly available information
• Define the lawful basis and purpose for collecting public data; scraping terms-of-service and robots.txt considerations.
• Treat aggregated or enriched profiles as Confidential or higher.
• Limit the application's own information leakage: generic error messages, suppressed server banners, stripped document metadata, no sensitive data in URLs or client-side code.
• Review what the organization publishes (API documentation, open-source repositories, job ads) to avoid exposing architecture details that aid attackers.
• Provide opt-out/removal mechanisms where people-search or data-broker style functionality exists.

6. Traceability
Every privacy requirement should be entered into a Requirements Traceability Matrix (RTM) and linked to design decisions, code, test cases, and acceptance criteria. This is how an auditor or assessor demonstrates compliance, and it is a recurring CSSLP theme.

Key Roles and Terms to Know
• Data subject – the individual the data is about.
• Data controller – determines purposes and means of processing.
• Data processor – processes on behalf of the controller (e.g., a SaaS vendor).
• Data owner / data steward / data custodian – organizational roles for classification, quality, and operational protection respectively.
• Privacy officer / DPO – accountable for privacy program and regulatory liaison.
• Privacy notice vs. privacy policy – external statement to users vs. internal governing document.

Exam Tips: Answering Questions on Handling PII and Publicly Available Information

1. Think "requirements phase" first. When a question asks when privacy should be addressed, the answer is almost always "during requirements gathering" or "as early as possible," not during testing or after deployment. Privacy by Design means built in, not bolted on.

2. Data minimization beats encryption. If answer choices include both "encrypt the data" and "don't collect the data unless necessary," the minimization answer is usually the best because it eliminates the risk rather than mitigating it.

3. Classification drives controls. If a scenario asks for the first step in protecting data, look for "identify and classify the data" or "perform a data inventory." You cannot protect what you have not identified.

4. Know anonymization vs. pseudonymization. Anonymization is irreversible and removes data from the scope of privacy law; pseudonymization is reversible with a key and the data remains PII. Questions often test this distinction.

5. "Public" does not mean "unprotected." If a question implies that information found on social media or public records needs no safeguards, be suspicious. Watch for the aggregation/mosaic concept: combining public data can produce sensitive data that must be protected.

6. Never log, display, or store more than needed. Options involving full SSNs in logs, CVV storage, unmasked data in UIs, or production PII in test environments are wrong answers. Look for masking, tokenization, and synthetic test data.

7. Recognize the regulatory match. Health data → HIPAA; payment card → PCI DSS; EU residents → GDPR (and DPIA, 72-hour breach notification, data subject rights); children under 13 in the U.S. → COPPA; financial institutions → GLBA; California consumers → CCPA/CPRA. The exam rarely requires deep legal detail but expects correct pairing.

8. Roles matter. The data owner (business) is responsible for classification and deciding protection levels; the custodian (IT) implements controls; the processor acts only on controller instructions. Choose answers that assign responsibility correctly.

9. Retention and disposal are requirements too. If a scenario describes data kept indefinitely, the gap is a missing retention/disposal requirement. Secure deletion must cover backups and all environments.

10. Traceability is the proof. When asked how to demonstrate that privacy requirements were met, look for the Requirements Traceability Matrix linking requirements to tests and acceptance criteria.

11. Eliminate absolute or reactive answers. Choices like "notify users after a breach occurs" or "rely on the firewall" address symptoms, not requirements. Prefer proactive, systemic, documented controls.

12. Read for the keyword "best" or "most." CSSLP questions typically contain several plausible options. Select the one that is most comprehensive, earliest in the lifecycle, aligned with policy and regulation, and risk-based rather than purely technical.

Summary
Handling PII and publicly available information in the CSSLP context means identifying and classifying data at the requirements stage, applying privacy principles (minimization, purpose limitation, consent, retention, individual rights), specifying concrete technical safeguards (encryption, tokenization, masking, anonymization, access control, secure disposal), recognizing that aggregated public data can become sensitive, limiting the application's own information leakage, and documenting everything in a traceable manner. Master these concepts and the reasoning patterns above, and the exam questions in this area become highly predictable.