Treat PII as Toxic: Designing Secure Systems That Contain the Blast Radius

PII Is Not "Just Another Field"

Most engineers treat all data in the same way, regardless of what it is. Names, Emails, Phone numbers, SSNs, etc., are stored as just another column in a table. In reality, not all data is equal, and considering them as equal is a dangerous mindset.

Some data is PII (Personally Identifiable Information), and mishandling it can lead to:

• Regulatory penalties
• Security breaches
• Reputational damage
• Legal exposure
• Loss of customer trust

If our system handles financial, healthcare, or identity data, PII handling becomes a crucial requirement. It is not only a security concern, but also a product and architecture concern. The way a system collects, stores, moves, and exposes PII should be intentionally designed from the beginning.

What Is Considered PII

PII is the information that can identify a specific individual. PII can be classified into three categories based on the sensitivity of data.

1. Critical Sensitivity

The breach of this data can cause severe harm. It can lead to identity theft, financial fraud, and physical danger. 

Below is some of the data that qualifies for this category:

• SSN
• Passport Number
• Driver's License
• Financial account details
• Medical/Health Records
• Passwords/Security Credentials
• Credit Card details
• Biometric data

2. High Sensitivity

These fields may not immediately enable fraud on their own, but they can enable fraud when combined with other data. 

Below is some of the data that qualifies for this category:

• Full Name
• Home Address 
• Phone Number
• Email address
• Date of Birth
• Tax Id/EIN
• Salary/Compensation data

3. Moderate Sensitivity

These field looks harmless individually, but can be used to identify individuals when combined with multiple other pieces of information.

Below is some of the data that qualifies for this category:

• ZIP code
• General location (city/region)
• IP Address
• Photos
• Browsing history

A common mistake is assuming that only highly sensitive fields are important. The reality is that attackers often combine data of moderate and high sensitivity from various sources to create the picture of an individual’s identity. Therefore, even if a field is classified as "low-risk," it is still important.

Core Principles for Handling PII

Consider PII as toxic data. These strategies should be applied when handling it. 

1. Data Minimization

Before collecting PII, consider the following questions:

• Do we really need this field?
• Can we partially store it?
• Can we tokenize it?

Best practice is to:

• Collect only what is needed
• Avoid logging PII
• Avoid passing between services

2. Encryption at Rest

All PII data should be encrypted when stored using robust encryption algorithms. This includes:

• Databases
• Backups
• Object Storage
• Disk volumes

Best practice is to:

• Never store the encryption key alongside data
• Use a key management system for storing the encryption keys and ensure keys are rotated during certain time frames

3. Encryption in Transit

All PII must travel over:

• HTTPS
• Encrypted internal service communication
• mTLS for service-to-service calls

4. Field-Level Encryption

If not all data needs to be encrypted, enforce field-level encryption in databases to store PII:

• Encrypt specific columns (SSN, bank account numbers)
• Decrypt only when required
• Restrict decryption access

This protects data in case the database is compromised.

5. Tokenization

Instead of storing raw PII:

• Replace it with a token
• Store actual value in a secure vault

Example:

Instead of storing

Plain Text
SSN: 123-45-6789

Store:

Plain Text
SSN_TOKEN: abc9x2k1

This reduces exposure across downstream systems that do not actually need the raw value.

6. Separate PII From Business Data

Store PII in:

• Dedicated tables
• Separate Databases
• Restricted schemas

This makes access control, auditing, and incident containment easier.

7. Enforce Strict Access Controls

No one should casually query production PII. 

Implement:

• Role-based access control
• Just-in-time access
• Service account isolation

Access should be granted only when there is a clear operational or business need.

8. Enforce Audit Logging

Audit logging should be enforced to track:

• Who accessed PII
• When PII gets accessed
• Why it was accessed
• From where is it accessed  

Alerts and monitors should also be in place to detect and trigger any anomaly.

9. Secure Retrieval of PII

 When retrieving PII:

• Validate authorization first
• Limit fields returned
• Avoid returning entire records
• Mask where possible
• Return partial PII where it suffice the use-case

10. Compliance Considerations

Depending on the industry, you may need to comply with:

• GDPR (EU)
• CCPA (California)
• HIPAA (Healthcare)
• PCI-DSS (Payments)
• SOC 2

 Common requirements include:

• Right to deletion
• Data access transparency
• Breach reporting timelines
• Data retention limits

11. Enforce Policies around Retention

PII is a liability to an organization and should not live forever. Policies should be made and enforced that define:

• How long data is retained
• When it is archived
• When it is permanently deleted
• Secure deletion mechanisms

12. Protect PII in Non-Production Environments

Many leaks do not occur in production. They happen in staging, QA, developer laptops, support tools, and exported CSV files.

Best practice is to:

• Never copy raw production PII into test environments
• Mask or synthesize data for testing
• Restrict access to internal admin tools
• Protect exported reports and downloadable files

A secure production database means very little if the same data is casually exposed somewhere else.

13. Prepare for Incident Response

Even with strong controls, incidents can still happen. Teams should know in advance what to do if PII is exposed.

This includes:

• Detecting the exposure quickly
• Revoking access
• Rotating credentials or keys if needed
• Identifying affected records
• Following legal and compliance reporting timelines
• Communicating clearly with stakeholders and customers

Security controls matter, but response readiness matters too.

Common Mistakes to Avoid

Some mistakes that are common but can cause a lot of damage should be avoided

• Logging full request payloads
• Sending PII to third-party analytics tools
• Sharing production DB dumps
• Hardcoding encryption keys
• Granting broad DB read access
• Storing PII in client-side storage
• Exposing PII to AI assistants

Cultural Mindset: Treat PII as Toxic

In high-risk industries, teams treat PII like hazardous material.

It should be:

• Isolated
• Minimized
• Encrypted
• Audited
• Monitored

That mindset changes engineering decisions. It forces teams to think about necessity before collection, protection before storage, and restriction before exposure.

Conclusion

Managing Personally Identifiable Information (PII) is not something we include in the list of features our application provides. It's not an add-on or a nice-to-have. Handling PII, as with all forms of sensitive data, is a holistic architectural challenge, and as a developer or an architect, we need to be aware of what's at stake.