A low-code platform reaches the security review with a working demo and a vendor questionnaire. The reviewer asks who can see customer records, where changes are logged, and how access ends when someone leaves. The demo answers none of those questions.
Internal tools connect to the same databases and APIs that hold revenue and customer data. One missing control in an internal dashboard can expose financial records or produce an audit finding. This checklist sets out the controls to verify before a platform reaches procurement. Each comes with a short definition, and a YAML version to copy sits at the end.
Three principles sit under every item:
Security is what the platform provides, plus how it is configured and operated.
An internal tool is held to the same standard as a customer-facing product.
Evidence is produced during the build, so it exists before the first audit asks for it.
Authentication
Authentication verifies the identity of a person or a system before it can reach data or functions. Passwords, tokens, single sign-on (SSO), and multi-factor authentication (MFA) are all forms of it. Systems authenticate too: API keys, OAuth flows, and service accounts verify automated requests between tools.
For internal tools, authentication should run through the company's identity provider, such as Okta, Microsoft Entra ID, or Google Workspace. The directory then decides who exists. Removing someone there removes their access to every tool that uses it.
Verify:
SSO over SAML 2.0 or OpenID Connect is supported, and mandatory for every user.
MFA can be enforced through the identity provider.
Sessions expire according to the company's policy.
No local passwords exist alongside SSO.
Group membership syncs from the directory and assigns roles.
Test onboarding and offboarding before launch. Add a user to a directory group and confirm the role appears in the tool. Remove the user and confirm the access ends.
Role-based access control
Role-based access control (RBAC) grants each person only the access their role needs, defined once per role rather than per user. Authentication confirms who someone is. RBAC decides what that person can see and change once signed in.
In Retool, permission groups control access to each app and to each data connection. Queries can also filter rows by the signed-in user's group, so a role sees only its own records.
Verify:
Custom roles can be configured to match the business roles.
Data is filtered by role at query level, rather than only hidden in the interface.
Permission changes are logged and can be reviewed.
Roles are assigned from directory groups through SSO.
Build the permissions matrix before building screens. Map every business role to the actions it takes and the data it needs. Enforce role changes at both the application and the database level. Test escalation, revocation, and privilege drift before launch.
Audit logging
Audit logging is a chronological, tamper-resistant record of who did what, when, and with what result. It begins where authentication and RBAC end, recording what happens after access is granted. An investigator, an auditor, or an incident review reads it as evidence.
An audit log captures four kinds of events:
Security events: sign-ins, failed sign-ins, permission changes, and MFA challenges.
Data changes: create, update, and delete, with the value before and after.
Workflow events: approvals, state transitions, and automated triggers.
System events: errors, configuration changes, and integration failures.
Each entry carries a timestamp, the user or service identity, the affected record, and the outcome. Automated workflows are logged in the same way as people, because an integration can change data too.
Verify:
Every action that changes data is logged.
Before and after states are recorded for each change.
Logs can be exported for review.
Retention matches the legal requirement.
Logs are append-only, and no user can edit or delete an entry.
Keep audit data in dedicated tables or an external log store, apart from business data. Restrict who can view or export logs. Never write sensitive field values to a log in plain text. Schedule exports to secure storage, and test that entries cannot be altered.
Encryption
Encryption converts readable data into ciphertext that only the holder of the right key can read. It protects data when other controls fail. An exposed storage volume or an intercepted connection then yields nothing readable. Data needs it in two states: in transit and at rest.
Verify:
TLS 1.2 or higher on every connection.
SSL enforced on every database connection.
AES-256 for data at rest and in backups.
Encryption keys controlled by the company, with a documented rotation schedule.
Backups and archives encrypted.
Keys belong in a key management service, never in application code or the browser. Audit every network and storage path, and confirm the cloud provider's default encryption is active. Keep the configuration and the test results as evidence for the review.
What compliance frameworks ask for
Auditors look for evidence that controls operate. Each framework sets its own emphasis:
HIPAA (US health data): log every access to protected health information, encrypt it at rest and in transit, and limit access to the minimum necessary. Required documentation is retained for 6 years.
SOC 2: log and monitor system activity, apply least privilege, and retain evidence for the committed period. SSO and MFA are expected.
GDPR (personal data of people in the EU): keep records of processing, apply data minimization, and support erasure and portability requests.
PCI DSS (cardholder data): encrypt with TLS and AES, restrict access to need-to-know, segment the network, and retain audit logs for at least 1 year.
Write down which control produces which piece of evidence before launch. Evidence the system generates is cheaper than evidence reconstructed by hand.
Signs a setup is not ready
No audit logging, so changes cannot be traced.
Shared credentials, so no action can be tied to a person.
Unencrypted connections between the tool and its data sources.
No SSO or MFA, so access depends on manual routines.
Accounts that outlive employment, because revocation is manual.
Every user on the same broad role.
APIs with no limit on bulk extraction.
A vendor that cannot answer certification or data residency questions.
After launch
Security review continues after go-live. Review access on a fixed schedule and remove permissions that no longer match a role. Run penetration tests, and treat medium and high findings as release blockers. Review logs for unusual patterns, and update the documentation when a workflow changes.
The databases, APIs, and cloud services behind the tool need the same controls as the tool itself. RBAC, encryption, and logging apply at every layer. What your security team will ask about low-code covers the questions behind this list. Four controls that make an internal tool safe to rely on covers the operating side.
The checklist
Copy this into the review ticket. Fill in each empty value, and link the evidence beside it.
authentication:
sso: { protocol: "SAML 2.0 or OIDC", mandatory: true, local_passwords: false }
mfa_enforced: true
session_timeout: "" # per company policy
directory_group_sync: true
offboarding_tested: false # remove a user in the directory, confirm access ends
access_control:
roles_matrix: "" # link: business role -> actions -> data
query_level_filtering: true
permission_changes_logged: true
escalation_and_revocation_tested: false
audit_logging:
events: [security, data_changes, workflow, system]
fields: [actor, timestamp, record, before, after, outcome]
append_only: true
export_for_review: true
retention: "" # set by regulation, e.g. PCI DSS: at least 1 year
encryption:
in_transit: "TLS 1.2+"
database_ssl_enforced: true
at_rest: AES-256
backups_encrypted: true
key_owner: company
key_rotation_schedule: ""
compliance:
frameworks: [] # HIPAA, SOC 2, GDPR, PCI DSS
control_to_evidence_map: "" # which control produces which proof
after_launch:
access_review_schedule: ""
penetration_test: { blocking_findings: [medium, high] }
log_review_owner: ""Our view
We recommend running this review before the platform reaches procurement, because each control shapes the data model and the access design. Adding audit logs or roles after people rely on the tool costs far more than configuring them first.
On Retool, most items map to settings the platform already provides: SSO, permission groups, permissions on each data connection, audit logs, and source control. The review then checks how those settings are configured. Custom code on the new Retool covers how the same controls apply to code written outside the builder. The product owner and the security team sign off the completed checklist, and it becomes the evidence pack for the audit.
