Shadow IT and Business-Built Apps: A Governance Playbook
Govern business-built apps by making the approved route easier than the shadow route. Register every app at intake, tier it by the data and decisions it touches, apply guardrails that scale with the tier, give builders an approved platform with identity and audit built in, and assign every app an owner, a review date and a retirement plan.
Disclosure: The author works at CloudApper, which makes the CloudApper AI platform, which is discussed in this article.
Key takeaways
- Shadow IT is usually a symptom of unmet demand, not bad intent. Bans push it further out of sight.
- The serious risks are data exposure, orphaned apps, accounts nobody reviews and decisions with no audit trail.
- Tier apps by risk so low-risk tools move fast and high-risk ones get real review.
- An approved platform with single sign-on, shared data and logging does more than a policy document.
- Every app needs a named owner and a planned end of life from day one.
Why do departments build their own apps?
Business teams build their own tools because the work cannot wait for the IT backlog. A plant manager needs a safety checklist this week. HR needs a way to collect shift preferences before the holidays. Finance needs a vendor intake form. Modern SaaS, no-code tools and AI assistants mean someone on the team can have something running by Friday, with a personal account and a credit card.
That speed is valuable, and governance should keep it. The problem is not that the business builds. It is that nobody knows what was built, who can see the data, or what happens when the builder leaves. This article focuses on the program for governing apps across the business. If your concern is specifically HR teams building AI agents that make decisions about people, see the compliance gap when HR-built AI agents make decisions. If you need to move a specific spreadsheet process, see how to replace spreadsheet workflows with governed enterprise apps.
What are the real risks of shadow IT apps?
| Risk | What it looks like | Why it matters |
|---|---|---|
| Data exposure | Employee or customer data copied into a tool with public links or weak sharing settings | Privacy obligations, breach notification, loss of trust |
| Orphaned apps | The builder changes roles or leaves; the app keeps running under their personal account | No one can fix, secure or shut it down |
| No access reviews | Accounts created outside single sign-on, never removed at offboarding | Former staff and contractors keep access |
| Audit gaps | Approvals and changes with no log of who did what | Cannot answer an auditor, regulator or investigator |
| Data drift | Each app keeps its own copy of employees, locations or vendors | Conflicting records and manual reconciliation |
Recognized frameworks treat these as basic hygiene. CIS Control 2, Inventory and Control of Software Assets, calls for actively managing all software so that only authorized software is installed and run. NIST SP 800-53 Rev. 5 includes account management (AC-2), system component inventory (CM-8) and audit and accountability controls. You cannot apply any of them to an app you do not know exists. The data drift problem is covered in our article on why a unified data layer matters for siloed app databases.
What does a governance playbook for business-built apps include?
1. Intake that takes five minutes
Ask builders to register an app with a short form: purpose, owner and backup owner, users, data types, integrations, and whether it supports a decision about people or money. Make registration a condition of getting single sign-on, shared data access or budget. Run a one-time amnesty for existing tools so teams can declare them without penalty.
2. Tiering by risk
| Tier | Typical example | Required controls |
|---|---|---|
| Tier 1: Low | Team task tracker, no personal data | Registration, owner, approved platform |
| Tier 2: Moderate | Internal request forms with employee names and contact details | Single sign-on, role-based access, annual review |
| Tier 3: High | Apps touching pay, health, hiring, customer data or financial approvals | Security and privacy review, audit logging, change control, quarterly access review, tested backup |
3. Guardrails, not gates
Most controls should be automatic: single sign-on through your identity provider, data connections only through approved connectors, logging switched on by default, and templates with approval steps already built. Reserve human review for Tier 3 and for changes that move an app up a tier. If roles and permissions already follow a design in your HCM, mirror it; our guide to designing role-based access with Workday security groups shows the thinking.
4. An approved platform
The single most effective control is giving builders somewhere better to build. The comparison of options in build, buy or platform for internal enterprise apps applies here. Look for identity integration, a shared governed data layer, logging, environment separation and admin visibility across every app.
5. Lifecycle and retirement
Every registered app gets a review date. At review, the owner confirms it is still used, the users list is right and the tier has not changed. Apps with no owner or no use in a set period are archived, with data exported or deleted under your retention schedule. Retirement is a planned event, not something that happens when a password stops working.
What do CISA and NIST say that applies here?
CISA's Secure by Design initiative asks software makers to build customer security into products by default so customers do not have to bolt it on. For internal apps, apply the same expectation to the platforms you approve: secure defaults should be the starting point, not settings builders must remember. The NIST Cybersecurity Framework 2.0 adds a Govern function covering roles, policy and oversight, which is where an app governance program belongs. For apps that involve code, NIST SP 800-218, the Secure Software Development Framework, describes practices for reducing vulnerabilities across the build process.
How to apply this: a worked example
Consider a hypothetical 2,000-employee healthcare services company. A brief survey and a review of single sign-on logs and expense reports turn up more than forty business-built tools, including a shift-swap app built on a personal account by a nurse manager who has since left. IT runs a 30-day amnesty, registers what it finds, and tiers each app. Low-risk trackers stay where they are with named owners. The shift-swap app, which holds employee contact details and schedule data, becomes Tier 2 and is rebuilt on the approved platform with single sign-on. Two apps handling patient-adjacent data become Tier 3 and go through full review. Eleven unused apps are archived.
Common mistakes
- Announcing a ban, which drives tools further underground.
- Applying Tier 3 review to every app, which recreates the backlog that caused shadow IT.
- Registering apps without owners, or with an owner and no backup.
- Allowing local accounts instead of single sign-on.
Where does the CloudApper AI platform fit?
An approved platform works only if it is a better place to build than the alternatives. The CloudApper AI platform is one option for organizations that want business-requested apps built on governed foundations. According to its site, apps are built from Governed Blueprints, described as auditable, structured logic, and share a Unified Data Layer instead of separate databases per app. The platform lists Unified Governance, Security by Design and consistent data access, and it describes zero maintenance through platform auto-updates and instant deployment with no infrastructure to manage. Named identity integrations include Okta, Ping Identity, OneLogin, Microsoft Active Directory and Azure Active Directory, and business system integrations include Workday, UKG, SAP, ServiceNow, Slack and Microsoft Teams.
No platform replaces the program itself. You still need intake, tiering, owners and retirement dates, whichever platform you pick.
Questions to ask any vendor
- Can every app use our identity provider for sign-in, with no local accounts?
- Do apps share one governed data layer, or does each create its own database?
- What is logged by default, and can we export logs to our security tools?
- Can admins see every app, its owner, its users and its data connections in one place?
- How are updates and security patches applied, and who is responsible?
- How do we archive an app and export or delete its data?
Frequently Asked Questions
What is the difference between shadow IT and citizen development?
Both involve people outside IT building or adopting tools. Shadow IT is unknown to IT and runs outside its controls. Citizen development is the same activity brought inside a governance program, with registration, approved platforms and owners. The goal of governance is to turn the first into the second without losing the speed that made it attractive.
Should we block unapproved SaaS and no-code tools?
Blocking high-risk categories can be appropriate, but blanket bans usually fail because teams find workarounds. A better approach is to offer an approved alternative, require registration for anything that touches company data, and use single sign-on and expense review to find what is still outside the program.
Who should own business-built apps?
A named person in the business should own each app's purpose, users and data, with a backup owner. IT or a platform team should own the platform, identity integration and security controls. Ownership should transfer formally when someone changes roles, and apps without an owner should be archived.
How often should access to business-built apps be reviewed?
Match the frequency to risk: quarterly for high-risk apps and annually for moderate ones is a common pattern. With single sign-on in place, offboarding removes access automatically, so the review mainly confirms that each user's role still fits, that the owner is current and that no local accounts have appeared.
Practical next steps for IT and business leaders
- Publish a five-minute intake form and announce a 30-day amnesty.
- Pull single sign-on, expense and browser extension data to find unregistered tools.
- Tier every registered app and assign an owner and backup.
- Choose an approved platform and make it the default for new requests.
- Set review dates and archive anything unowned or unused.
For more on governing technology in HR and across the enterprise, see our AI in HR guides.
Last reviewed: October 2026.
Sources
- SP 800-53 Rev. 5: Security and Privacy Controls for Information Systems and Organizations, National Institute of Standards and Technology
- CIS Control 2: Inventory and Control of Software Assets, Center for Internet Security
- Secure by Design, Cybersecurity and Infrastructure Security Agency
- CloudApper AI Platform, CloudApper
Comments
Post a Comment