A low-code security review answers a short sequence of questions, and the checklist below is simply those questions in the order they have to be settled: who owns this application by name, which guardrails belong to the platform and which to you, what the connector policy permits, and which verification controls remain the maker’s own work.
Quick Overview
What you’ll learn:
- Why the inventory has to come from the admin console, not from asking teams
- Where the platform’s responsibility stops and the organisation’s begins
- How connector policies block data paths rather than banning tools
- Which verification controls survive the move to low-code unchanged
Who this article is for:
- Platform administrators running Power Platform or comparable low-code estates
- Team leads whose applications are built outside the IT department
- People accountable for personal data processing in the organisation
Reading time: 7 minutes
Who Owns This Application
The question is deliberately narrow: not which team sponsors the app, but which named person answers for it. An application without a named owner has no review, no decommissioning trigger and nobody who notices that it has been mailing a spreadsheet to a personal address since spring. Low-code shadow IT is rarely defiance — the tooling is available to everybody and the register is not.
An inventory entry earns its place when it answers, without a conversation, who owns the app, what data it reads, which systems it connects to and which environment it runs in. Maker and owner are different roles: the maker may leave the company, the owner is a position a successor inherits.
Microsoft’s Center of Excellence guidance on learn.microsoft.com describes the starter kit as tooling that collects telemetry on the tenant’s apps and flows and surfaces them to administrators. The point worth taking is the direction of collection: the register is populated by the platform, not by a survey. A survey returns the applications somebody remembers.
Which Guardrails Are Yours
Shared responsibility is misleading in low-code because the platform genuinely absorbs a great deal — runtime, patching, encryption at rest, user authentication. What it cannot settle on your behalf is the only question that matters at a data boundary: who should see which records, and for what purpose.
So the second step is to write the boundary down against a real application rather than a diagram. Take one app and, for each control, record whose it is: encryption at rest belongs to the platform; the scope of rows a connection returns belongs to the maker; granting access to the data source belongs to the environment administrator; the lawful basis for processing belongs to the data protection officer. A control with no name next to it is a gap, not an ambiguity.
The SSDF on csrc.nist.gov frames the same split from the production side, grouping secure development practices into preparing the organisation, protecting the software, producing well-secured software and responding to vulnerabilities. A low-code app is software, so those practices apply to it; the difference is that the platform performs some of them for you. The boundary runs inside those groups, not around them.
What the Connector Policy Permits
This is the step that changes behaviour before a single screen exists. The connector classification documentation on learn.microsoft.com sets out the Business, Non-Business and Blocked data groups of a policy, with a connector residing in only one group at a time. The data policy guide from the same source names the effect: moving a connector into the business group prevents makers from building apps and flows that combine it with connectors in the non-business or blocked groups.
The consequence is more useful than a ban: the policy does not forbid tools, it forbids bridges. A connector to the corporate database and a connector to an external note-taking service can both exist, just not inside the same application. That is precisely the exfiltration path a review of the finished app is least likely to spot, because on screen it looks like ordinary copying.
Items to tick here: the production environment has an additional environment-scoped policy, since tenant-level policies already apply to it; custom connectors are classified explicitly, because the policy will not classify them for you; and the default group for newly added connectors stays non-business — the documentation recommends exactly that, and a connector added to the platform after the policy exists lands there.
Which Controls Stay the Maker’s Own
The ASVS on owasp.org organises verification requirements into chapters — from authentication and session management through authorisation and input validation to logging and error handling. Low-code platforms tick several of those chapters for you, but authorisation and input validation stay with the maker, because they follow from what the application is for.
The same findings recur in reviews. First, the app hides a button from an unauthorised user while the underlying data source still returns the full record set — hiding an interface element is not access control. Second, the app writes an audit trail into a table nobody reads and that has no access control of its own.
The Proactive Controls list on owasp.org is the better companion for makers than a requirements standard, because it is written as design guidance rather than as a verification checklist: enforce access controls server-side, validate inputs, handle errors deliberately, log security events. Those four read the same whether the screen was typed or dragged.
Access reviews close the checklist and are the only recurring step. Events trigger them, not the calendar: an owner change, a new data source, a widened scope on an existing connection, a leaver. An annual review in an organisation where applications appear within a week describes a state that has already moved on.
Read Also
- Low-code / no-code: when it’s the right choice for your business — the platform decision that precedes securing it
- Low-code / no-code platforms: rapid application development — what gets built on these platforms and how fast
- Microsoft Power Platform: Power Apps, Power Automate, Power BI guide — the components and their place in the architecture
Build Your Skills
This topic is covered by Low-Code/No-Code — Power Platform, Mendix, OutSystems and Low-Code for business — building applications without coding. The first compares platforms and their governance mechanisms; the second works through building an application without a development background. Talk to us about matching the scope to your organisation.
Frequently Asked Questions (FAQ)
Are low-code applications less secure than hand-written code?
They distribute risk differently. The platform removes whole classes of implementation defect, because the maker writes no session handling and no database queries. In exchange, permission and data-flow risk grows, because applications appear faster, more often and outside the IT department’s review. Securing them is therefore environment governance rather than code review.
Where do we start when applications already exist and nobody knows how many?
With a list pulled from the platform’s admin console, and an owner assigned to each row even provisionally. Policies come after the inventory: a DLP policy introduced first will block live processes you did not know about, and the rollout stops at the first escalation.
Is a DLP policy enough to satisfy data protection obligations?
No, because it settles whether a data path is technically possible, not whether the processing is lawful. A low-code app handling personal data needs a documented purpose, a defined data scope and an assessment by the data protection officer, exactly as any other system does. The policy is a technical measure supporting that assessment, not a substitute for it.
Who should be accountable for an application built by a business team?
The named application owner in the inventory, rather than the IT department as a body. IT owns the environment, the policies and the control standard; the owner answers for whether the application still does what its register entry says, and reports any change in data scope. Without that role an access review has no addressee and will not happen.