The internal tool is finished, and the security review sends back four questions. Who can see and change which records? Where does the data go? How do the integrations authenticate? What can the audit log prove?
Every low-code review returns to these four. A platform such as Retool supplies the controls behind each answer: SSO, permission groups, encrypted connections, audit logs, and separate environments. The review passes or stalls on whether those controls are configured, documented, and checked. This piece sets out what a reviewer expects under each question, and the evidence that answers it.
Access control: who can see and change what
The reviewer wants least privilege, enforced by the platform and tied to the company directory.
What answers it:
Sign-in through the identity provider. Users authenticate through Okta, Microsoft Entra ID, or another SSO provider, with multi-factor authentication enforced there. There are no local passwords.
Roles from the directory. Directory groups map to the platform's permission groups. A person who leaves the company loses access everywhere when their directory account closes.
Read and write held apart. For each role, write down which screens and records it can view, and which it can change. These are separate decisions.
Access at the data connection. Each data connection carries the narrowest credentials that work. Every app that uses the connection inherits that limit, so one rule covers many apps.
Regular access reviews. A named owner reviews permission groups on a fixed schedule, and removes access nobody can justify.
Informal access is the usual finding. Admin roles handed out as a shortcut, and groups that no longer match real teams, are what reviewers flag first.
Data exposure: where the data goes
The reviewer wants to know which data the tool touches, where it is stored, and who can see it on the way.
What answers it:
A data inventory. List each system the tool reads from and writes to, and the classification of the data in each.
Encryption. Data is encrypted in transit and at rest. State how, and where the keys are managed.
Deployment location. Say where the platform runs: the vendor's cloud in a named region, your own VPC, or on-premises. For data residency, this answer decides the review.
No production data in development. Test environments use anonymized or synthetic data. Separate environments make that enforceable.
Monitoring that stays in bounds. Error logs and call stacks can carry personal data too. Keep them inside the same boundary as the data itself.
That last point is often missed. One regulated client needed error monitoring under Canadian data residency rules, where call stacks could not leave the country. The answer was a monitor built inside its own Retool deployment, described in error monitoring in Retool, without a log leaving the region.
Integrations: how connections authenticate
Each integration is a path into another system. The reviewer wants each path scoped, logged, and owned.
What answers it:
Scoped credentials. OAuth or API tokens limited to the operations the tool needs. A service account with full write access fails review.
Credentials held by the platform. Secrets live in the platform's resource settings, not in app code or a shared document.
Vetted third parties. Each external API has a named owner, a reason to exist, and a check on the vendor's own security posture.
Patching and updates. Custom components and libraries get updated on a schedule, with known issues tracked.
Logging and alerting. Integration calls are logged, and unusual patterns raise an alert to a named owner.
Compliance and audit: what the log can prove
Finance, healthcare, and public-sector reviewers all ask the same thing in different words. Can you show who changed what, when, and why?
What answers it:
Audit logs on every write. Actor, timestamp, and the value before and after, retained for as long as the regulation requires.
Version control. Every change to the tool has a history, a reviewer, and a way to roll back.
Approval on sensitive writes. Changes to live records in high-risk workflows wait for a named person to approve them.
Reporting without a scramble. Audit evidence can be produced on request, ideally from a saved query rather than a manual export.
Periodic outside review. An external auditor or penetration test validates the controls. Medium and high findings are fixed before release.
Platform certifications such as SOC 2 and ISO 27001 cover the vendor's side. Your configuration is the other half, and the reviewer will ask for both. Requirements such as GDPR or HIPAA are met by how the platform is deployed and configured, on top of what the vendor certifies.
What to send the reviewer
A review moves faster when the answers arrive before the questions. A short pack covers most of it:
An architecture diagram showing each data connection and where it runs.
The role matrix: each role, what it can view, what it can change.
The SSO and multi-factor configuration.
A sample of the audit log, showing actor, timestamp, and before and after values.
The vendor's certification reports, and your own penetration test results.
The security and compliance checklist turns these into a list you can run before procurement. Four controls that make an internal tool safe to rely on explains why each one matters after launch.
Our view
Low-code is secure enough for enterprise use when the controls are configured deliberately and documented. We recommend building the access model, the data inventory, and audit logging into the first sprint, because each one shapes the data model. Added after launch, each becomes a retrofit that holds up the review. The product owner and the security team sign off the configuration together, and the tool ships against it.
