PII Data Handling: A Practical Guide for App Teams

PII data handling means deciding what personal information your business collects, where it lives, who can see it, how it is protected and when it is deleted. The best approach is to decide this before you write code: collect less, restrict access, encrypt what you keep, delete on a schedule and have a breach plan ready. At Let’s Build My App, we build products with senior US-based engineers, so these choices get made by the people who write the software.

This guide is for founders and teams shipping or running an app. It follows US federal guidance, mainly from the FTC and NIST, and keeps the jargon low.

TL;DR

• PII is any information that can identify a person, alone or when combined with other data. A name is PII, and so can be a device ID plus a ZIP code.
• Start with the FTC’s five actions: take stock, scale down, lock it, pitch it, plan ahead.
• The safest PII is data you never collected. Every field in a sign-up form should have a business reason.
• Encrypt PII in transit and at rest, limit access to people who need it, and delete it when the purpose ends.
• Write your breach plan before you need it. All 50 states have breach notification laws, and the deadlines differ.

Table of Contents

• What counts as PII
• Step 1: Take stock of where PII lives
• Step 2: Collect and keep less
• Step 3: Classify the data
• Step 4: Control who can access PII
• Step 5: Encrypt and secure stored PII
• Step 6: Mind where data lives and which laws apply
• Step 7: Delete PII on a schedule
• Step 8: Plan for a breach before it happens
• What you should not do with PII
• A short checklist for founders
• Our perspective
• Build your app with PII handling designed in
• FAQ
• Sources

What counts as PII

NIST, the US standards agency, defines PII as information that can distinguish or trace an individual’s identity, alone or when linked with other information. Its examples include names, Social Security numbers, passport and driver’s license numbers, financial account numbers, addresses, phone numbers, biometric records, and IP or MAC addresses.

Two ideas matter for app teams.

Direct and indirect identifiers. A name or SSN points to a person directly. A birth date, ZIP code or device ID may not on its own, but combined they often do. The USDA’s fact sheet makes the same point: information can be PII without a name when it is linked or linkable to a person, and combining separate datasets can create PII.

Context decides sensitivity. NIST says how much protection data needs depends on how easily it identifies people, how many people are involved, how sensitive the field is and how the data is used. A list of customer emails for a newsletter is lower risk than the same list attached to health or financial details.

Five quick examples you will meet in almost any app: name, email address, phone number, date of birth and a government ID number. If your product also takes payments, health details or location, treat those as higher sensitivity.

Step 1: Take stock of where PII lives

You cannot protect data you have not found. NIST recommends identifying PII across databases, shared drives, backups and contractor-maintained sites before choosing safeguards.

For an app, build a simple data map. List:

• Every field you collect (sign-up forms, checkout, support chats, file uploads).
• Every system that stores it: your production database, analytics tools, email platform, CRM, error logs, backups and spreadsheets.
• Every third party that receives it through an API or integration, such as payment processors, email services and AI tools.
• Who on your team and which vendors can access each location.

Where it goes wrong: PII spreads into places nobody planned. Debug logs capture request bodies. Support staff export customers to spreadsheets. A test database is a copy of production. These forgotten copies are where leaks often start.

This step is easiest when it happens during product design. Our product strategy and project management work for MVPs puts the data your app collects on the table early, with the engineers who will build it in the room. For an existing app, a project rescue is a natural moment to map where personal data ended up.

Step 2: Collect and keep less

NIST advises minimizing PII collection, use and retention to what is strictly necessary for the business purpose, and reviewing collected data from time to time to see whether you still need it. The FTC’s guide is blunt on the same point: don’t collect or hold sensitive information without a legitimate business need, avoid using SSNs unnecessarily, and don’t retain payment card data you don’t essentially need.

A practical test for every field: what feature breaks if we don’t ask for this? If the answer is “none,” remove the field.

Examples:

• Ask for a birth year or an “I am over 18” checkbox instead of a full birth date when age is all you check.
• Use a payment processor’s hosted checkout so card numbers never touch your servers.
• Show the last four digits of an ID in the interface instead of the whole number.
• Don’t log full request bodies in production.

Where it goes wrong: teams collect “just in case” data for future features. Each extra field adds risk and adds work when you have to protect, search and eventually delete it.

Step 3: Classify the data

Not all PII carries the same risk. The FTC suggests classifying information by impact so the strongest controls go where a leak would hurt people most. A workable scheme has three tiers:

The last row needs care. Datasets that look anonymous can be combined with other data to re-identify people, so re-check any “anonymous” export before sharing it.

Step 4: Control who can access PII

The FTC says to limit access to employees who need it for their jobs. In an app, that becomes concrete decisions:

• Role-based access. Support sees what support needs. Marketing sees aggregates. Only a small group has database access.
• Strong logins. The NIST Privacy Framework guide for small businesses recommends controlling logins and devices, using security software, making regular backups and automating security updates where possible.
• Careful sharing. The Department of Homeland Security’s handbook advises minimizing duplication and dissemination of sensitive PII and redacting anything beyond what the recipient needs before emailing, printing or copying.
• Physical basics. For paper and removable media, the FTC suggests locked rooms or cabinets, clean desks, workstation locking and restricted off-site storage access.

Where it goes wrong: access granted once and never removed. When someone changes roles or leaves, their permissions should change the same day. Vendors and contractors count too. If your app was built on a platform or by a team you no longer work with, check who still holds keys.

Step 5: Encrypt and secure stored PII

Encryption turns readable data into scrambled data that is useless without a key. The FTC recommends encrypting sensitive information sent over public networks and considering encryption for stored data, portable media and internal email that contains personal information. It also recommends current anti-malware, vulnerability monitoring and vendor-approved patches. NIST’s small-business guide adds encrypting sensitive data both at rest and in transit.

In plain terms:

1. Use HTTPS everywhere, including internal admin tools.
2. Turn on encryption for databases, file storage and backups.
3. Keep secrets such as API keys out of your code repository.
4. Apply security updates promptly.

If your app uses a chatbot to collect customer details, masking PII before it is stored matters too. A walkthrough of chatbot security best practices covers the controls to check on that kind of channel.

If your product sits on Bubble or another no-code platform, our guide on no-code security checks before launch shows what to review. When a product outgrows a platform’s controls, a Bubble-to-code migration moves it onto custom software where your team decides how data is stored and protected.

Step 6: Mind where data lives and which laws apply

There is no single US privacy law covering all PII. Requirements depend on your industry, your users’ states and where they live.

• Financial data. The CFPB’s 2024 personal financial data rights rule requires covered providers to make consumer data available securely to consumers and authorized third parties. It took effect January 17, 2025, with phased compliance from April 1, 2026 through April 1, 2030.
• Mobile apps. The California Attorney General’s mobile guidance recommends need-to-know access, encryption in transit and storage, and PCI DSS compliance when an app collects payment card information.
• Users outside the US. If you have European users, see our overview of GDPR for US startups. For questions about where servers and databases sit, read what data residency rules require for US apps.

If you are in a regulated field such as banking, healthcare or insurance, ask your attorney which rules apply to your product before launch. Rules change, so confirm with the official source for your state and sector.

Step 7: Delete PII on a schedule

The FTC’s “pitch it” principle means disposing of what you no longer need. NIST’s small-business guide calls for formally disposing of data and old devices.

Build a retention schedule into the product:

• Set a time limit for each data type (for example, inactive accounts, abandoned carts, support transcripts).
• Make deletion real: remove records from the database, backups on rotation, search indexes and analytics exports.
• Let users request account deletion, and make sure it reaches every system on your data map.
• Wipe or destroy retired laptops, drives and paper records.

Where it goes wrong: deletion is built for the main database and forgotten everywhere else. This is why the data map in step 1 pays off twice.

Step 8: Plan for a breach before it happens

NIST recommends a PII breach-response plan that sets out when and how to notify individuals, how to report, and whether to offer remedial services such as credit monitoring, with privacy, IT, security and legal staff working together.

The Vermont Attorney General’s guidance gives a clear order of action: isolate affected systems, preserve logs and evidence, involve law enforcement, contact the data owner if you hold someone else’s data, and notify consumers as quickly as possible, subject to state deadlines. The FTC’s guidance, as summarized by the National Law Review, adds investigating root causes, closing vulnerabilities and third-party access, and considering credit monitoring when SSNs or financial data are exposed.

All 50 states have security breach notification laws, and they vary in what counts as a breach and how fast you must notify. If a breach happens, contact an attorney early to confirm which states’ deadlines apply to your users.

Your plan fits on one page:

1. Who leads the response, and who is on call.
2. How to isolate systems and keep logs.
3. Who calls your attorney and your insurer.
4. A draft notice you can adapt.
5. A list of states where your users live.

If you collect support or sales conversations through a chatbot, this chatbot PII masking guide shows how masking reduces what a privacy incident can expose.

What you should not do with PII

Based on the guidance above, avoid these:

• Collecting or keeping sensitive data with no business purpose.
• Using SSNs as a general-purpose ID.
• Storing payment card data you do not need.
• Giving everyone on the team access “to be safe.”
• Copying production data into test environments or spreadsheets.
• Emailing unredacted records when a smaller extract would do.
• Keeping data indefinitely because deletion is inconvenient.

NIST also notes that privacy risk is broader than cybersecurity risk: even without a hack, how data is processed can cause embarrassment, discrimination or economic loss. Decide what you do with data, not only how you guard it.

A short checklist for founders

• [ ] Data map of every field, system and vendor that touches PII
• [ ] Each field tied to a feature that needs it
• [ ] Data tiers defined, with stronger controls for sensitive data
• [ ] Role-based access and same-day permission removal
• [ ] Encryption in transit and at rest, plus backups
• [ ] Retention periods and working deletion
• [ ] One-page breach plan and an attorney you can call

Our perspective

Most PII problems we see in app projects begin as product decisions, not security ones. A form gets one field too many, an integration receives more data than it needs, or a prototype’s shortcuts stay in production.

That is why we think handling PII belongs in the build, not after launch. When senior engineers talk directly with you about what the app collects and where it goes, the right answer is usually to collect less and connect fewer things.

It is also why we work the way we do: US-based senior engineers, direct access to the people writing your code, and a fixed price agreed up front. You can make privacy decisions early, when changing them is cheap, and keep them in place after launch.

If your product has outgrown its no-code platform or needs a stronger foundation, a migration is a good moment to rebuild your data handling properly.

Alex

Build your app with PII handling designed in

If you are launching a first product, modernizing business software or moving off a no-code platform, our team designs and builds web and mobile apps with senior US-based engineers, typically shipping in 6 to 10 weeks. Pricing is fixed and agreed up front. Our published monthly plans start at $1,750 for Starter, $3,000 for Growth and $5,000 for Enterprise, with a Custom option, all on our pricing page.

To talk through what your app will collect and how it should be protected, scope your project with our team. Post-launch support and maintenance is part of our service, so the work continues after your app goes live.

FAQ

What is PII data handling?

It is the set of rules and routines for how you collect, store, use, share and delete personal information. Good handling means collecting only what you need, restricting access, encrypting data, deleting it on a schedule and having a breach plan.

What are five examples of PII?

A name, a Social Security number, a driver’s license or passport number, an email or street address, and a date of birth are common examples. NIST also lists biometric records and IP addresses. Data can also become PII when it is linked to a person.

How do you handle PII data in an app?

Map where it lives, collect only what each feature needs, classify it by sensitivity, limit access by role, encrypt it in transit and at rest, and set retention and deletion rules. Then write a breach plan so you can act quickly if something goes wrong.

Which activities are not acceptable when handling PII?

Collecting or retaining sensitive data without a business need, using SSNs unnecessarily, storing payment card data you do not need and giving broad access to people who do not need it. Also avoid copying PII into emails, spreadsheets or test systems without redaction or controls.

Sources

• NIST SP 800-122, Guide to Protecting the Confidentiality of PII
• USDA Enterprise-Wide Safeguarding PII Fact Sheet
• FTC, Protecting Personal Information: A Guide for Business (2016)
• FTC, Protecting Personal Information: A Guide for Business (full PDF)
• NIST, Protecting Personally Identifiable Information
• NIST, Getting Started with the NIST Privacy Framework
• DHS Handbook for Safeguarding Sensitive PII
• California Attorney General, Privacy on the Go
• CFPB personal financial data rights final rule, Federal Register
• Vermont Attorney General, Security Breach Guidance
• National Law Review, FTC Issues Guidance for Responding to Data Breaches
• NCSL, Security Breach Notification Laws

Recommended

• ADA Compliance Apps: What to Use and How to Build Right
• Stop Leaking Keys: Secure Bubble API Connector and the :join Fix

About Let’s Build My App

Let’s Build My App is a US-based AI development agency. We design, build, and launch production-grade custom software using AI coding tools including Claude Code and OpenAI Codex, and we migrate legacy Bubble apps onto AI-coded stacks such as React, Supabase, and Firebase. We are the #1 US-Based Bubble Agency, founded and run by Alex Dow. Book a free strategy call to scope your project.