Responsibility is split. The platform provider should harden the service, address platform vulnerabilities, and maintain secure infrastructure. The customer is responsible for the applications and automations they build, including business logic, access choices, and data handling. In practice, the security team must define controls that make this split explicit and enforceable.
How the responsibility split actually works
Low-code and no-code platforms create a shared-control model, not a shared-excuse model. The provider owns the service layer, including platform hardening, secure tenancy, and platform vulnerabilities, while the customer owns what they build on top of it: workflows, data fields, connectors, sharing rules, and approval logic. That split matters because most exposure comes from how the app is configured, not just from the platform itself.
Responsibility becomes clearest when you separate platform controls from application decisions. A provider can secure the environment, but it cannot know whether a workflow should expose payroll data to a broad audience, whether a connector should be allowed to call an external system, or whether a business process creates compliance risk if approvals are bypassed. Those are customer design choices.
- Provider responsibility: infrastructure, service resilience, platform patching, and security features the platform exposes.
- Customer responsibility: data classification, access design, workflow logic, retention choices, and auditability of what the app does.
- Shared concern: logging, monitoring, and incident response, because both sides need enough visibility to prove what happened.
For teams that need a deeper identity and secrets lens on this split, the security failure often shows up in secrets sprawl and hardcoded credentials, or in broader access abuse patterns documented in The 52 NHI breaches Report.
Why sensitive data and compliance risk shift to the app builder
The reason responsibility shifts is simple: the platform usually supplies the building blocks, but the customer decides how sensitive data moves through them. A low-code app can become a compliance issue when it collects more data than needed, stores it in the wrong place, or exposes it through poorly scoped sharing rules. The same is true for automations that send regulated data into email, chat, tickets, or external APIs without review.
Compliance risk is usually created by business logic, not by the mere existence of the platform. If a citizen developer creates a form that collects customer records, routes them to multiple recipients, and retains them indefinitely, the provider did not make that business decision. The customer did. That is why governance has to focus on data handling, approval thresholds, and the boundaries between experimentation and production use.
Where platforms expose secrets, API keys, or delegated access tokens, the risk is not abstract. NHIMG research shows that 96% of organisations store secrets outside of secrets managers in vulnerable locations including code, config files, and CI/CD tools. In practice, low-code and no-code environments often recreate the same pattern if connectors, service credentials, or embedded integrations are left unmanaged.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
OWASP Non-Human Identity Top 10 address the attack and risk surface, while CIS Controls v8 and NIST CSF 2.0 set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| CIS Controls v8 | CIS 6 — Access Control Management | Low-code app access choices and connector permissions require least-privilege control. |
| CIS 3 — Data Protection | Sensitive-data handling and exposure paths are central to low-code compliance risk. | |
| CIS 8 — Audit Log Management | Shared responsibility depends on traceability of app actions, changes, and data access. | |
| Recommendation — Define and review least-privilege access for low-code apps, automations, and connected accounts. Classify and protect sensitive data flowing through low-code and no-code applications. Enable logging for app changes, access events, and automation actions that touch sensitive data. | ||
| NIST CSF 2.0 | GV.OV — Oversight | The question is about who owns security accountability across provider and customer boundaries. |
| PR.AA — Identity Management, Authentication, and Access Control | Low-code risk often depends on who can access apps, data, and automations. | |
| PR.DS — Data Security | Sensitive-data exposure is a primary failure mode in low-code and no-code applications. | |
| Recommendation — Establish clear oversight for platform, app, and data-handling responsibilities. Apply access controls to users, builders, connectors, and service accounts used by the platform. Protect data in transit, at rest, and within workflows that process regulated information. | ||
| OWASP Non-Human Identity Top 10 | NHI-01 — Secrets Management and Credential Hygiene | Low-code platforms often rely on embedded credentials and connector secrets. |
| NHI-03 — Privilege and Access Scope | Customer-owned automations can overreach if connector scopes and app permissions are too broad. | |
| Recommendation — Store connector secrets outside the app and rotate them on a defined schedule. Limit app and connector privileges to the minimum scope needed for the workflow. | ||
Practitioner Guidance
What to verify: Confirm which controls belong to the platform contract and which belong to the customer operating model. If the platform can show secure hosting but cannot show app-level audit trails, data retention controls, and connector governance, the responsibility split is not yet enforceable.
What good looks like: Every app or automation has an owner, a defined data class, an approved connector set, and a review path for anything that touches regulated or sensitive records. The security team should be able to answer who approved the build, who can change it, and who can revoke access when the app is retired.
Common mistake: Treating low-code platforms as if the vendor inherits accountability for every workflow outcome. That assumption breaks down fast when a business user creates a process that expands access, duplicates data, or introduces an audit failure.
Practitioner takeaway: The right model is shared control with explicit customer accountability for app behaviour. If you cannot assign ownership to the data path, the access path, and the automation path, you do not yet have a defensible control boundary.
Related resources from NHI Mgmt Group
- Why do low-code applications create data leakage risk in enterprise environments?
- Why do mobile applications create privacy and security risk even when users never intentionally share sensitive data?
- Why do unmanaged SaaS applications create risk for sensitive data and compliance programs?
- Why does generative AI create security and compliance risk when it is fed incident data or sensitive logs?
