Title banner for 'Before you build an internal app.' A 'convenience vs. control' balance in the center, builders (individual/department) on the left, IT/governance on the right, and the three pillars — operations, security, licensing — along the bottom.

Key Points

  1. Building internal apps in-house is fast and fits the field — but always at the cost of governance, handover, security, and licensing. Treat "convenience vs. control" as a trade-off from the start.
  2. Who this is for: both the people building internal tools (individuals, departments) and those who approve and govern them (IT, owners). No prior knowledge needed.
  3. What you get: place yourself on the shadow-IT → citizen-development → in-house gradient, an escalation-path table for exposure scope, the three pillars (operations / security / licensing) with minimum lines, a region-by-region read of secure-development regulation (US / EU), and a pre-release checklist ordered by what hurts most if deferred.
  4. Out of scope: the final call on a specific app, your org's shadow-IT policy (ask IT), cross-border transfer of personal data (ask legal/DPO), network design (enterprise network basics), transport encryption (communication security), and dependency-license specifics (OSS licenses).

この記事の要点(日本語版はこちら)

  1. 社内アプリ内製を「作る/許可する」両視点で扱う 日本語版 もあります。これは翻訳ではなく、法域別に書き分けた姉妹記事です(本稿は米国・EU のセキュア開発規制を主軸にしています)。

As of: 2026-06 / Focus: building small-to-mid internal apps (individual / department / small team), US & EU secure-development context / last_updated: 2026-06-11 Changelog: 2026-06-11 first published as an international (US/EU) edition

Educational material, not a substitute for professional judgment

Internal apps touch areas that — depending on how they are handled — can spill into data breaches, regulatory violations, or policy breaches (personal-data law, , OWASP Top 10–class vulnerabilities, shadow IT, AI-generated-code term violations, and so on). This article is a general, educational overview, not advice on any specific implementation or matter, and it makes no warranty as to accuracy, completeness, or currency. For production decisions, always consult your IT / information-security team, in-house legal / DPO, a security specialist, and whoever owns your AI-use guidelines. This information is provided "AS IS." Neither the author nor YATA-NODE is liable for any loss or damage arising from its use or reliance on it.

About this series: this piece takes the view of the side that builds internal apps. It sits on top of enterprise network basics, communication security, and virtualization & sandboxing, plus dependency visibility via SBOM tooling and OSS licenses. Each reads on its own.

A few terms (for newcomers):

  • Shadow IT: tools or SaaS built or used by individuals/departments outside IT and legal oversight — convenient, but the location of data, contracts, and licenses becomes invisible.
  • Citizen development: business-side non-engineers building apps inside a company-selected low-code platform (Power Platform / kintone / AppSheet). Unlike shadow IT, it is under approval.
  • Zero trust: don't assume "inside the corporate network = safe"; verify every access, per-session, with least privilege (foundation: enterprise network basics).
  • SBOM (Software Bill of Materials): an inventory of the parts (dependencies) a piece of software uses, down to transitive ones — used to track licenses and vulnerabilities (SBOM tooling).

In-house is fast — but you trade control for it

Here's the conclusion first. Building internal apps in-house buys you speed and a tight fit to the field, in exchange for costs in governance, handover, security, and licensing. Convenience and control are inherently a trade-off, and facing that balance up front makes every later decision quicker.

A balance of the merits and demerits of in-house building. Left pan: merits (fast changes, field fit, low cost, self-reliance). Right pan: demerits (weak governance, key-person risk, security/licensing risk, ongoing operational load).

Merits — why teams build in-house — come down to four: speed (the long "spec → order → delivery" cycle disappears), field fit (people who know the work build it, so requirements rarely get lost), cost (small needs that wouldn't justify an outside quote get picked up), and self-reliance (the department improves things itself, without waiting on IT).

The demerits are the flip side: governance (shadow IT growing outside oversight hides where data, contracts, and licenses live), key-person risk (when the author leaves, no one can touch it — the "bus factor of 1" problem), security / licensing (missing input validation, an exposure-scope slip, or an unchecked component can turn one person's mistake into a company-wide incident), and ongoing operational load (shipping with no tests or monitoring leaves you blind when something breaks).

The key point: the interests of the governing side and the builders do not fully align. Management worries about loss of control and reputational fallout; builders carry the handover burden and the lock-in at departure. So the realistic answer is not "ban it or govern everything," but to keep the convenience while bolting on a minimum of control — starting by locating where you stand.

Where are you now? — the shadow-IT → citizen-development → in-house gradient

Internal apps aren't a binary of "shadow IT vs. proper in-house." They form a gradient across actor, approval, exposure scope, and control. Start by locating where you (or your department) stand today.

A gradient of in-house apps. X-axis: exposure scope (individual → department → company-wide → external). Y-axis: governance strength (individual judgment → approval → IT-managed). Shadow IT sits lower-left, citizen development in the middle, in-house development upper-right, on a continuum.
CategoryActorApprovalControlTypical example
Shadow ITindividual / dept on their ownnoneoutsidea Python script on a personal PC, unsanctioned SaaS
Citizen developmentbusiness-side non-engineersyes (platform chosen)mediuma low-code app on Power Platform / kintone
In-houseIT / dev orgyesinsidea company web service, internal platform

What matters in practice: shadow IT arises naturally. When IT is slow or existing systems don't fit, the business side chooses "I'll build it myself." Banning that outright just drives it underground, so the realistic governance move is to pull it into an approved low-code environment (= citizen development).

Reverse-engineer the "escalation path" of exposure scope

Internal apps tend to escalate: "a tool for me → handy, so shared in the team → a department tool → used company-wide." Work out, at each step, what the next step requires, and the cost of catching up later drops.

ScaleExposureControl loadMinimum to reach the next step
Personal toolown devicelow (mind confidential data)docs, secret management
Small-team sharedept / VPNmedium+ auth + backups + a runbook
Department appdept / related deptsmedium–high+ request approval, SSO, log aggregation
Company-wideall staffhigh+ monitoring + alerts + audit logs + disaster recovery
Externalthe internetmaximum+ WAF + pen testing + incident response

This is the read for the governing side (IT, owners). Whether to permit, escalate, or stop a department's build depends on which step it is trying to climb to in the table above. Demand company-wide controls of a personal tool and you kill the seedling; allow external exposure with only a personal tool's controls and you get an incident. Handing over the minimum line that matches the step is the way to govern without crushing initiative — and builders who self-report "what's missing" before climbing get approved faster.

If you build it: the three pillars — operations, security, licensing

Whatever step you're on, a running app rests on three pillars: operations / maintainability, security, and licensing. Drop one and it stops working as a pillar. You don't need perfection — first meet the minimum line, and raise it toward the intermediate line as the step rises.

The three pillars supporting an internal app: operations/maintainability, security, and licensing/performance/logging hold up the roof of 'a running app'; remove one and it tilts.

Pillar ① Operations / maintainability — the minimum for "it keeps running even after the author is gone."

  • Put the code in Git + a README covering "what, why, how to run it" (the start of de-keypersoning).
  • One smoke test (/health check) + automated lint / format.
  • Monitoring starts at /health + one alert; intermediate is the metrics / logs / traces trio.

Pillar ② Security — begins by dropping "inside = safe" (zero trust, below).

  • Input validation (allowlist), parameterized queries for SQL, context-aware escaping for XSS.
  • Data minimization: don't collect, expose, or retain what you don't need. Keep secrets (passwords / tokens / PII) out of logs.
  • Exposure scope: distinguish localhost from 0.0.0.0; don't expose /admin or .env in production.
  • Auth: hash passwords and ride company SSO; add MFA where you can.
  • AI-generated code: watch for copied training code and licensing (if your AI coding assistant can suppress/flag output matching public code, enable it); keep secrets out of prompts. Wiring SCA / SAST + license checks into CI is the intermediate line.

Pillar ③ Licensing / performance / logging — where "it was actually in there all along" hurts most later.

  • Check direct-dependency licenses, and ideally cover transitive ones with an (specifics → SBOM tooling and OSS licenses).
  • Performance: avoid premature optimization — measure, then fix. Set P95-latency and monthly-cost targets before going live.
  • Cloud cost: budget alerts + guarding against "forgot to stop it" (TTL tags / auto-delete). Cases where a forgotten instance ran up to tens of thousands of yen a month are not rare.

The app itself should assume zero trust

Zero trust isn't only a network-side concern; the app itself must not assume "the corporate LAN is safe." Large breaches have repeatedly shown that "once you're inside the perimeter, you can see everything" is a false premise. The core of the US NIST guidance on zero-trust architecture (NIST SP 800-207) is organized as several tenets; summarized for implementation as three points: ① treat all resources as things to protect, ② authenticate and encrypt all communication (regardless of network location), ③ evaluate access per-session with least privilege. In an app, that becomes: split DB users into read / write / admin, issue API tokens per-purpose with minimum scope, and never make "logged in once = trusted forever" (the network-side foundation is enterprise network basics).

Secure-development regulation by region — and why it keeps shifting

Once a build touches the EU market, an overseas subsidiary, or an overseas client, secure-development regulation descends as "a requirement on your development process." The three regions differ in how they drive it (snapshot as of June 2026; the US side in particular is fluid).

United States — procurement-driven, with a 2025–2026 rollback

The US has driven secure development by requiring it of vendors that sell to the federal government, making it a de-facto market baseline. The stack built up as:

  • EO 14028 (May 12, 2021) directed NIST to define a secure-development framework and seeded SBOM requirements for federal software.
  • NIST SSDF (SP 800-218 v1.1, Feb 2022) — the practical framework, in four groups: PO (prepare the org) / PS (protect the software) / PW (produce well-secured software) / RV (respond to vulnerabilities). SP 800-218A (Jul 26, 2024) extended it to generative-AI / dual-use foundation models.
  • OMB M-22-18 (Sep 14, 2022) required agencies to collect a self-attestation of SSDF conformance from vendors; CISA's common attestation form followed (Mar 11, 2024).

Then came the rollback. The point to take away is not the political back-and-forth but the structural result:

  • EO 14144 (Jan 16, 2025) reinforced EO 14028 and pushed secure-development clauses and attestation verification toward the Federal Acquisition Regulation (FAR).
  • EO 14306 (Jun 6, 2025) removed part of that attestation-verification requirement — while keeping NIST's secure-development tasks intact.
  • OMB M-26-05 (Jan 23, 2026) rescinded M-22-18 / M-23-16, moving from a blanket self-attestation mandate to each agency's risk-based approach; the common form and SBOM clauses survive as optional tools.

So the technical framework (SSDF) survives, while the machinery that forced it through procurement was dismantled. The lesson for internal-app builders: the SSDF practices (PO/PS/PW/RV) remain best practice, but institutional enforcement swings with the administration. Separately, the industry standard SLSA (Supply-chain Levels for Software Artifacts; OpenSSF, with v1.0 published Apr 19, 2023 and a later spec version current since) gives a common language for build-pipeline integrity.

European Union — the CRA and the revised PLD put obligations on software

The EU uses law itself. First, the beginner trap — the difference between a Regulation (directly applicable across the EU once in force) and a Directive (effective via each member state's transposition, so timing can vary by country). With that in mind, two laws hit app development directly:

  • Cyber Resilience Act (CRA) = Regulation (EU) 2024/2847 (a Regulation). For manufacturers of "products with digital elements": secure development from design, vulnerability handling during the support period, and an SBOM as part of the technical documentation. Key dates: vulnerability/incident reporting obligations from Sep 11, 2026, full application Dec 11, 2027.
  • Revised Product Liability Directive (PLD) = Directive (EU) 2024/2853 (a Directive). Strict (no-fault) liability, with the definition of "product" now explicitly including software (standalone, , AI systems); non-commercial FOSS and mere source code are excluded. Transposition deadline Dec 9, 2026.

A purely internal tool isn't usually a CRA "product," but shipping your software into the EU market — or building a component that goes into a CRA-covered product — can trigger manufacturer duties. NIS2 (Directive (EU) 2022/2555) reaches app developers indirectly, via regulated customers passing requirements down the supply chain. And if you embed high-risk AI (Annex III uses) into an in-house app yourself, the EU (Regulation (EU) 2024/1689) provider duties can apply (full application Aug 2, 2026). Merely using third-party AI is the lighter deployer role — though deployers of high-risk AI still carry duties (human oversight, use per instructions, log-keeping), and putting your own name on a system or making a substantial/purpose-changing modification can pull you into provider duties.

International standards and the Japan contrast

Region-independent de-facto standards form the common language: OWASP Top 10 (2025 version, which added "A03 Software Supply Chain Failures"), OWASP ASVS v5.0.0 (2025), and the two SBOM standards — = ISO/IEC 5962:2021 and CycloneDX = ECMA-424. Japan, by contrast, runs on guidelines and procurement criteria rather than horizontal hard law: METI's "Guide to Introducing SBOM" (a procurement/transaction guide, not a mandate) and the Digital Agency's "Security by Design" guideline (DS-200).

The practical implication: enforcement strength differs by region, but the substance — secure development, vulnerability management, dependency visibility via SBOM — is nearly common, and sits on the same foundation as the three pillars above.

Before you ship — what hurts most if deferred, plus a checklist

As a rule of thumb, some items cost exponentially more the later they surface. Clear them in order and you'll have fewer regrets:

  1. Data classification (if not fixed at planning, the design leaks confidential data into general logs)
  2. Where auth goes (bolting guards on later means touching the whole app)
  3. Licensing policy (discovering " was actually mixed in" later forces a halt or rewrite)
  4. Exposure-scope design (building on localhost then running on 0.0.0.0 and exposing it company-wide by accident is the classic incident)
  5. Log-level design (cleaning up after writing everything at INFO is misery)
  6. Ownership handover at departure (found after someone leaves, regaining access takes months)

The checklist below works as a pre-release self-check (you don't need a "yes" to all — meeting what your step requires is enough):

text
[Pre-release checklist — internal apps]
□ Planning: data classification fixed; the personal/confidential data handled is documented
□ Planning: checked your IT / infosec team's guidelines
□ Licensing: checked direct and transitive dependency licenses (via SBOM if possible)
□ Licensing: checked the terms of AI-generated code and assets (images, fonts)
□ Security: input validation (allowlist) implemented
□ Security: parameterized queries for SQL, context-aware escaping for XSS
□ Security: auth/authorization not skipped "because it's internal" (SSO / MFA)
□ Security: exposure scope considered; no /admin or .env exposed
□ Security: secrets (passwords / tokens / PII) not written to logs
□ Ops: README has purpose, run steps, and a contact
□ Ops: code in Git; ownership-handover steps for departures
□ Ops: at least one smoke test (/health)
□ Perf: targets set (P95 latency / concurrent users / monthly cost cap)
□ Perf: cloud budget alert set; TTL management in place

It comes down to three things: ① convenience and control are a trade-off (not binary — bolt on the minimum line that matches the step), ② locate your step on the gradient and reverse-engineer the escalation path, and ③ stand up the three pillars — operations, security, licensing — at the minimum line first. Combined with enterprise network basics, communication security, virtualization & sandboxing, SBOM tooling, and OSS licenses, the "build / approve" call gets noticeably faster.

References

Secure development and operations for internal apps are guided by public standards and laws (versions and dates change over time; everything reflects what we could confirm as of June 2026).

United States

European Union

International standards

This series also covers enterprise network basics, communication security, virtualization & sandboxing, SBOM tooling, and OSS licenses.

On AI assistance: This article draws on the author's hands-on experience, used Claude (Anthropic) as an aid for research, structuring, and summarization, and was then composed after the author verified primary sources (public standards, statutes, government documents). Versions and effective dates reflect what was confirmed at the time of writing (June 2026); the US procurement side in particular is fluid.

About the author

More than 20 years of electrical and software development — from control engineering at a major electronics manufacturer — plus about 10 years of solo development. Across hardware and software, and across enterprise and individual work, I publish the basics that "become a risk if you don't know them." More at About this blog.