A no-code form or site builder can be safe enough for customer data, but only after you check who can see the submissions, where the data is stored, which connections move it onward and what gets logged. The builder's defaults are rarely tuned for sensitive data, so test before you collect any.
Why this question comes up
A marketing team builds a sign up form in an afternoon. It collects names, emails and perhaps more. No developer reviewed it, no one recorded it, and submissions flow into a spreadsheet and a messaging channel. The OWASP Citizen Development Top 10 lists sensitive data leakage and handling failures as a core risk, and this is the typical shape of it.
Six checks before you collect data
| Check | What to look for |
|---|---|
| Who can see submissions | Named people only, not anyone with a link |
| Where the data is stored | A location you can name, with access control and a retention period |
| Where it goes next | Every connected tool, such as email, chat, spreadsheets and CRMs |
| What the form collects | Only what you need, with no sensitive fields by default |
| Who can edit the form | A small group, since an edited form can redirect data |
| What is logged | Access and changes, without storing the data itself in logs |
Step by step
- List the data fields and ask for each: do we need it? Drop what you do not.
- Open the form as an outsider, in a private window, and try to reach the results page, exports or any shared link.
- Draw the path of one submission, from the page to its final resting place, including notifications and backups. Every hop is a copy.
- Check the connections. Each should use a dedicated account, not a person's login, and each should have an owner.
- Test input handling by submitting odd values, such as very long text and special characters, and confirm they are stored as plain text and not run.
- Decide the retention. Delete submissions you no longer need.
- Write a one line privacy notice that matches what actually happens.
Our post on mapping where data goes in a multi hop low-code workflow covers step 3 in detail.
Questions your customers may ask
They may ask where the data is stored, who can access it, how long you keep it and whether the tool is on your approved list. Having these answers written down, even in a few lines, speeds up reviews.
When to say no
Do not use a casual no-code builder for health details, payment card data, government identifiers or anything your regulator treats as especially sensitive. Use a reviewed system built for that purpose, or ask your security team. Regulatory questions are for your legal advisers.
Keep a register
Add each form to your app and bot inventory with an owner and a review date. Forms are easy to forget and easy to leave public. See how to build a low-code app inventory in one week.
Where Safeguard fits
Safeguard's API security scan demo shows how an exposed endpoint is tested. If a form posts to an API you operate, scanning that API is a useful check. Free scan at https://gold.safeguard.sh/scan.
Try it yourself
Open the demo and look at how an API scan reports an endpoint that exposes more than it should. Think about whether a form you built posts to an endpoint like that.
Click through it at your own pace, or open it full screen.
Quick check
Is a private link the same as private data?
No. Anyone with a link may be able to open it. Test access from a browser where you are not signed in.
Do we need approval for a one off form?
If it collects personal data, yes, even briefly. Ask for a quick review and a delete date.
Sources
Last reviewed: 19 October 2026.
