What does it collect?
Name every field, upload, message, export, and connection.
Contents — choose a chapter
1
When a small app becomes responsible for information
A prototype crosses a line the moment you type in a real name, copy a customer message, save an internal note, or connect it to another business system.
That does not make the app automatically unsafe. It means the experiment now has consequences. A wrong color or awkward button is inconvenient. A private note shown to the wrong person, a lost record, or an automatic promise sent to a customer is different.
Why is each item needed?
Connect the field to the first process, not a vague future possibility.
Who can use it?
Separate viewing, changing, approving, exporting, and deleting.
How will you recover?
Know who notices a mistake and how the business returns to a safe state.
The owner's role
Security is not one switch a developer turns on at the end. You do not need to implement every technical control, but you must describe the business meaning those controls protect.
2
Draw the data journey
Follow one fictional inquiry through every place its information travels.
InName, reply method, request, date
StoredOwner, status, notes, next action
UsedStaff review and prepare a response
SharedA reviewed reply or approved export
RemovedTest or expired records leave safely
Include exports, email, spreadsheets, integrations, backups, logs, and printed copies. Information is not protected merely because the main screen requires a password.
For each stage, name a person who owns the decision. “The system handles it” is not an owner. Someone must know who may correct a record, approve a connection, restore a backup, and decide when information should be removed.
3
Collect less: Need, Nice Later, Leave Out
The easiest sensitive field to protect is the one the first version never collects.
The process stops without it
- Reply method
- Request
- Date and status
- Assigned owner
A future version may use it
- Marketing preferences
- Detailed profile
- Additional integrations
- Historical import
No clear purpose here
- Passwords
- Payment-card data
- Identity documents
- Unrelated personal history
Do not disguise speculation as a requirement. “We may want it one day” belongs in Nice Later. If a field is needed only for a rare exception, consider handling that exception outside the first version.
Data minimization in plain language
Collect for a reason, keep for a reason, and remove when that reason and any applicable obligation have ended. This guide does not invent a universal retention period.
4
Separate fictional, copied, and live information
Begin with invented records. Move toward real information only when lower-risk tests have passed.
| Kind | Meaning | Use during the first pilot |
|---|---|---|
| Fictional | Invented people, requests, addresses, and amounts. | Begin here |
| Copied and changed | A realistic shape from which names and identifying details have been removed. | Use carefully |
| Live | Current information about a real customer, employee, supplier, or transaction. | Introduce deliberately |
Changing one name may not make a record safe. A distinctive request, address, photograph, account number, or combination of details may still identify someone or reveal confidential business information.
Mark every invented record visibly, such as TEST — Rosa's Bicycle Repair. Never paste passwords, secret keys, full payment-card data, identity documents, or regulated records into a general-purpose coding or AI tool merely to make a test realistic.
5
Decide who can see and change what
“Everyone on the team” is rarely a useful access rule.
| Role | May view | May change | May approve |
|---|---|---|---|
| Owner or administrator | All inquiry records and access settings | Records, assignments, configuration | Users, exports, deletion, live launch |
| Assigned staff member | Records assigned to them | Status, work notes, next action | A reviewed reply within policy |
| Occasional helper | Minimum records needed for the task | The specific step they own | Nothing outside that task |
| App or automated job | Fields required for its narrow function | Drafts, flags, reversible changes | Nothing consequential without a person |
Give each person a separate account. Remove access when a role ends. Use multifactor authentication where the service supports it, especially for administrative access. Avoid shared administrator credentials and keep secret keys out of notes, source files, screenshots, and email.
Prove the boundary
Sign in as a limited user and confirm the account cannot see another person's records, change settings, or reach an administrator screen by editing a web address.
6
Keep consequential actions behind human approval
Let the app prepare work without giving it permission to complete every action.
THE APP MAY
Collect consistent fields, show missing actions, prepare a draft, flag waiting work, and display history.
✓
A PERSON APPROVES
Messages, promises, prices, payments, deletion, exports, permissions, and sensitive exceptions.
If AI is involved, begin in draft-for-review mode. Human review is a real control only when the reviewer has enough context, time, and authority to stop the action.
Four questions
If the app is wrong, who notices, how quickly, can the action be reversed, and what evidence will show what happened?
7
Back up the information and rehearse recovery
A message that says “backup complete” is not the same as a proven recovery.
Write down what is backed up, where it exists, who controls the account, how often it is created, who notices a failed backup, and how to restore one record or the whole app.
- Create two marked fictional records.
- Make or confirm a backup.
- Change one and delete the other.
- Restore into a safe place.
- Confirm the information is complete.
- Record time and missing instructions.
Do not damage live information to prove recovery. A developer or hosting provider may need to create an isolated restore environment. Uploaded files may use different storage from text records and need their own recovery plan.
Backup is not version control
GitHub can preserve application code and change history. It does not automatically back up a production database, uploaded documents, or third-party service configuration.
8
Run the five-case safe pilot
Run the app beside the current process while a person remains in control.
1Normal caseA complete inquiry follows the expected path from arrival to replied or closed.
2Missing informationThe app identifies what is absent without inventing an answer.
3DuplicateStaff recognize and resolve the duplicate without losing history.
4Sensitive exceptionThe app stops, restricts access, or hands the decision to a person.
5Mistake and recoveryA wrong status or deleted test record is corrected or restored.
Let at least one person who did not build the app perform realistic tasks. Observe rather than coaching every click. The goal is to discover what the app makes unclear.
First-App Data Boundary and Safe Pilot Card
Fill it in here, copy a blank template, or print this card.
1. Data journey
2. Field boundary
3. Access and human approval
4. Backup and recovery
5. Five-case pilot
| Case | Expected safe result | Observed result | Status |
|---|---|---|---|
| Normal | |||
| Missing information | |||
| Duplicate | |||
| Sensitive exception | |||
| Mistake and recovery |
6. Decision
9
Record problems, corrections, and surprises
Write down observed friction instead of collecting an unlimited wish list.
- Task attemptedWhich pilot case or real task was underway?
- ExpectedWhat did the person reasonably think would happen?
- ObservedWhat actually happened, without guessing the technical cause?
- ConsequenceWas it confusing, blocked, exposed, lost, or merely inconvenient?
- Safe next actionWho owns the decision, and what must be retested?
Prioritize anything that prevents a record from reaching “done,” reveals information to the wrong person, creates an unreviewed commitment, or makes recovery uncertain. Cosmetic wishes can wait.
A change is not verified because code was edited or a developer says it is fixed. Repeat the affected case and keep the observed result.
10
Move into real work gradually, or stop
Review the card with the person responsible for the work and make one deliberate decision.
KeepThe tested boundary works
FixA specific defect blocks use
NarrowRemove data, access, or action
ExpandAdd one tested capability
StopPreserve learning; return safely
If live use begins, start with a small number of records and named users. Monitor access, errors, backups, unusual cases, and external actions. Review the boundary whenever the app gains a new integration, user role, data type, automatic action, or public page.
The useful result
The goal is not merely “we launched software.” The business should understand what the app knows, what it may do, who remains responsible, and how to recover.
Use this alone, or bring the card to BrainIT
Nothing here requires a sales call. The Data Boundary and Safe Pilot Card is yours to copy, print, and use. If you would like a second pair of eyes, I can review the boundary with you, help run the five cases, or perform a focused security scan before live information is introduced.
Emile du Toit · BrainIT Consulting
brainitconsulting.com
Sources and limits. This guide draws on official guidance from the FTC, NIST, SBA, Digital.gov, and CISA. The worksheet and five-case pilot are BrainIT teaching devices, not official government checklists.
FTC: Start with Security · FTC: Protecting Personal Information · NIST: CSF 2.0 Small Business Quick-Start Guide · SBA: AI for small business · NIST: AI RMF Core · Digital.gov: Usability testing. Accessed July 28, 2026.
This is general educational guidance, not legal advice, a compliance certification, or a guarantee against loss. Requirements vary by industry, jurisdiction, contract, and the kind of information involved.