Every organization knows it has shadow IT. The figure that makes the problem concrete: most organizations run more than 1,000 cloud applications, and IT typically has visibility into fewer than 10 percent of them. Large enterprises average 473 SaaS applications; IT directly manages only a fraction. Eighty percent of employees use unsanctioned applications to get their work done. The numbers are consistent across every study because the dynamic they reflect is consistent: employees and business units adopt tools that solve immediate problems faster than IT governance processes can evaluate and approve them.
The 2026 conversation about shadow IT is dominated by SaaS discovery tools that scan DNS logs, analyze SSO OAuth tokens, audit expense reports, and fingerprint network traffic to find cloud applications that employees are using without authorization. These tools solve the SaaS layer of the problem, and they solve it reasonably well. What they do not solve, and what no SaaS discovery tool addresses, is the other shadow IT problem: the custom-built applications, undocumented batch programs, informal data pipelines, and ghost utility programs that exist in enterprise application portfolios and have never appeared in any asset management system, change log, or IT inventory. These are not cloud applications deployed by employees. They are production programs, running on mainframes and midrange systems, performing business-critical functions that the organizations that own them cannot fully account for.
The two problems require different discovery approaches. The SaaS shadow IT problem requires network visibility and identity integration. The code-level shadow IT problem requires parsing the actual software artifacts, source code, load libraries, JCL job streams, to enumerate what programs exist and what they do. This guide covers both, with a specific focus on the second category that the rest of the field has not addressed.
Know the Dependency Graph
SMART TS XL extracts business rules, dependency maps, and dead code across COBOL and legacy programs.
FIND OUT MORE…The Two Shadow IT Problems
Shadow IT is typically defined as technology used within an organization without explicit IT approval or knowledge. That definition covers two fundamentally different phenomena that require different discovery approaches and different governance responses.
Shadow SaaS and cloud tools are applications and services adopted by employees or business units without formal IT procurement. A marketing team using an unapproved AI writing tool. A finance team sharing spreadsheets through a personal Dropbox account. A developer using an unauthorized AI coding assistant that sends proprietary source code to an external API. These applications exist outside the organization’s infrastructure and are discoverable through external signals: DNS queries, OAuth authorizations, expense report line items, network traffic fingerprints.
Shadow application software, the category this article focuses specifically on, is custom-built programs and batch processes that were created within the organization’s own infrastructure and never properly documented, inventoried, or governed. A COBOL program written by a developer in the finance department in 1994 to handle a specific tax calculation edge case. An RPG program created by a business analyst to generate EDI files for a specific trading partner. A JCL job that runs every month-end and produces a regulatory report that the compliance team depends on, built by a contractor who left the organization in 2009. A Java utility written “temporarily” during a systems integration project in 2018 that became a permanent dependency without anyone deciding it should.
These programs are not visible in DNS logs because they run on internal infrastructure. They do not appear in OAuth authorization records because they predate OAuth. They are not in the official application inventory because they were never formally submitted for IT governance review. They are discoverable only by examining the infrastructure itself, the load libraries, source code repositories, job schedulers, and execution logs that reveal what software actually runs in the environment.
The reason this matters beyond inventory completeness: 74 percent of organizations have experienced security incidents due to unknown or unmanaged assets. Shadow application software represents the category of unknown assets that neither network-based discovery tools nor SaaS visibility platforms can find.
Why Shadow Application Software Accumulates
Understanding why undocumented custom applications proliferate in enterprise environments explains why standard governance processes fail to prevent it and why retrospective discovery is necessary.
The immediate solution imperative. Business units face specific operational problems that require specific solutions. The approved application does not handle the edge case. The IT request queue is backlog-constrained. A developer, sometimes in IT, sometimes embedded in a business team, writes a solution that works. The solution runs, solves the problem, and becomes part of the operational workflow. The formal governance process never happens because the problem is already solved.
The temporary-that-became-permanent pattern. The most insidious form of shadow application software begins as an explicitly temporary solution. “Just until the real system is ready.” “A quick workaround for the data format issue.” “Temporary while we wait for the vendor to fix their API.” Temporary solutions become permanent when the dependencies that accumulate around them are never dismantled. The COBOL date calculation fix written for Y2K remediation that is still being called twenty-five years later because no subsequent developer knew why it existed or whether it was safe to remove. The “temporary” database normalization script that became part of the nightly batch because the target application was never actually built.
The knowledge transfer failure. Shadow applications built by specific individuals leave the organization’s documented knowledge when those individuals leave. The program continues running, it is embedded in production processes that depend on it, but no documentation exists, no ownership is assigned, and no one knows what it does in sufficient detail to change it safely. It becomes a ghost in the production environment: visible in its effects, invisible in its governance.
The shadow data pipeline. Data integration is a particularly fertile ground for undocumented custom software. When the official ETL layer does not support a needed transformation, or when a business process requires data to move between systems faster than the official integration process allows, developers build unofficial data movement programs. A Python script that queries the production database and writes results to a shared drive that a downstream process picks up. A COBOL program that reads from the mainframe DB2 and writes to a flat file that a cloud application ingests. These unofficial data pipelines cross system boundaries, handle potentially sensitive data, and operate entirely outside the integration governance framework.
The Four Categories of Shadow Application Software
Category 1: Business-Unit Custom Applications
Programs built by developers embedded in business units, finance, procurement, operations, compliance, that solve specific domain problems. These programs typically:
- Are named informally (TAXCALC, VENDREPT, ADJBATCH) without following enterprise naming conventions
- Live in directories or libraries managed by the business unit rather than IT
- Have no entry in the configuration management database (CMDB)
- Have no assigned technical owner in IT’s service management system
- Lack formal documentation, test coverage, and change control history
Their criticality is frequently understated because the business unit knows what the program does and considers it “theirs.” The IT organization, which does not know the program exists, cannot score its criticality. The program’s absence from IT’s application inventory means it is absent from BCP, disaster recovery planning, security assessments, and modernization program scope.
Category 2: Ghost Programs
Programs that appear in production execution but whose origin, purpose, and ownership are unknown to the current organization. They exist in load libraries and source repositories, they are called by other programs or invoked by JCL jobs, they produce outputs that downstream processes depend on, but the organizational memory of why they exist and who is responsible for them has been lost.
Ghost programs are particularly dangerous from a security and compliance perspective because they cannot be reviewed against current standards, cannot be included in vulnerability scanning programs that require application ownership to be assigned, and cannot be assessed for regulatory compliance because nobody knows what data they access or what business function they serve.
Category 3: Shadow Data Pipelines
Unofficial programs that move data between systems outside the sanctioned integration architecture. These range from sophisticated ETL alternatives to simple file-transfer scripts:
python
# Typical shadow data pipeline -- production database to shared storage
# Written 2021, "temporary until the API is ready"
# Still running daily as of 2026, owner left organization 2022
import pyodbc, shutil
from pathlib import Path
conn = pyodbc.connect('DSN=PROD_BILLING;UID=svcacct;PWD=...') # hardcoded creds
cursor = conn.execute("SELECT * FROM BILLING_RECORDS WHERE STATUS = 'PENDING'")
rows = cursor.fetchall()
# Write to shared drive that Finance picks up
output_path = Path(r'\\FILESERVER01\Finance\billing_export.csv')
with output_path.open('w') as f:
for row in rows:
f.write(','.join(str(v) for v in row) + '\n')
shutil.copy(output_path, Path(r'\\ARCHIVE\billing\') / f"billing_{date.today()}.csv")This program, representative of a pattern found across enterprise environments, uses hardcoded production database credentials, writes sensitive billing data to a shared network location without encryption, and has been running unmonitored for years after its author left the organization. It would not appear in any SaaS discovery tool because it runs on internal infrastructure. It would not appear in network traffic analysis because it uses standard database protocols that produce no distinguishable signature. It is visible only in the source code itself.
Category 4: Undocumented Batch Jobs
JCL job streams and scheduled programs that run on production infrastructure but are absent from the official job schedule documentation. These accumulate through:
- Jobs submitted outside the standard job scheduler through direct submission
- Programs called dynamically from within other programs (and therefore not independently visible in scheduler inventories)
- Jobs that run infrequently, at month-end, at year-end, or only when specific business conditions occur, and have never been captured in routine inventory audits
- Jobs inherited from predecessor systems that were “migrated” but never formally decommissioned
Undocumented batch jobs become critical failure points when:
- A maintenance window impacts the system they run on, and nobody knows to notify the business unit that depends on their output
- A security assessment is performed and these jobs run as unmonitored service accounts with elevated privileges
- A modernization program scopes migration based on the documented job schedule and arrives in the target environment missing critical batch processing
Discovery Methods by Shadow Software Category
The discovery methods appropriate for SaaS shadow IT are largely inapplicable to shadow application software. The methods required are:
Load library analysis. Every program that has ever been compiled and deployed to a mainframe or midrange system exists in a load library, the executable repository. Comparing the programs in the load library against the programs in the official application inventory reveals the gap: every load module that appears in the library but not in the inventory is a shadow program. This analysis requires no source code, it operates on the compiled executables and their metadata.
Source repository traversal. Source code repositories (COBOL source PDSs, Git repositories, RPG source libraries) contain every program ever written, including programs that were written informally, deployed informally, and never registered in IT governance systems. Traversing the full source repository against the CMDB reveals programs that exist in source but have no governance record.
JCL and scheduler reconciliation. Every JCL job stream that executes in production, whether submitted through the official scheduler, submitted manually, or invoked by another job, leaves a trace in the job execution log (JESLOG, SYSLOG). Comparing the programs that appear in production execution logs against the programs in the official inventory identifies programs that run in production without governance coverage.
Dynamic CALL analysis. Programs that call other programs dynamically, where the called program name is determined at runtime rather than at compile time, create dependencies that are invisible to static scheduler analysis. Dynamic CALL analysis traces which programs issue CALL statements with variable program names, identifies the range of programs that could be called, and flags programs reachable through dynamic dispatch that may not appear in any static dependency map.
Data flow tracing. Shadow data pipelines are discoverable through analysis of file-system and database access patterns: which programs read from or write to which datasets, files, or database tables. A program that reads from a production database and writes to a file path outside the standard data management hierarchy is a shadow pipeline candidate.
The Shadow AI Dimension
The 2026 extension of the shadow IT problem is shadow AI, employees and business units using AI tools and agents without IT authorization. According to IBM’s 2026 Cost of a Data Breach report, 43 percent of security incidents involve workers using shadow AI. Gartner predicts that by 2030, more than 40 percent of enterprises will experience a security or compliance incident linked to unauthorized shadow AI.
The specific risk that shadow AI introduces that is directly relevant to code-level shadow IT: proprietary source code going into AI coding assistants. An employee who uses an unauthorized AI coding assistant to help with a legacy COBOL program has sent that program’s source code to an external AI provider. The source code may contain hardcoded credentials, business logic that constitutes trade secrets, or data structures whose exposure violates data residency requirements. The discovery method for this specific risk is not network traffic analysis, it is detecting which programs have been accessed by tools that communicate with external AI APIs, which requires application-level monitoring rather than network-level monitoring.
The shadow AI problem and the shadow application software problem share an important characteristic: both are invisible to the network-based discovery tools that dominate the SaaS shadow IT market. Both require either application-level monitoring or structural code analysis to surface.
Building the Complete Application Inventory
The output of a shadow IT discovery program for enterprise application software is a reconciled inventory that covers four populations:
Known and documented: Programs that appear in both the official inventory and the actual production environment. These programs have governance coverage, assigned owners, change control history, disaster recovery plans.
Known but not deployed: Programs that appear in the official inventory but cannot be found in load libraries or production execution logs. These are candidates for retirement, they may have been decommissioned without proper formal retirement, or they may be listed incorrectly.
Unknown but deployed (shadow programs): Programs that appear in production execution logs or load libraries but have no entry in the official inventory. These are the core shadow IT finding, programs that require immediate ownership assignment, security assessment, and governance registration.
Undocumented dependencies: Programs that appear in neither the official inventory nor the primary production execution logs but are discovered through dynamic CALL analysis or data flow tracing as reachable from production processes. These are the ghost programs, the hardest to find and the most dangerous to leave undiscovered.
The reconciliation between these four populations produces the action plan: register the shadow programs, assess their security posture, assign ownership, and determine their disposition, govern and maintain, modernize, or retire.
How SMART TS XL Performs Code-Level Shadow IT Discovery
SMART TS XL’s approach to shadow IT discovery addresses the code-level categories that network-based tools cannot reach.
The static code analysis capability begins with complete source repository traversal: every COBOL program, RPG module, PL/I application, Java service, Python script, and JCL job stream in the environment is catalogued with its source location, language, size, and preliminary complexity profile. This inventory is the baseline against which the CMDB and official application registry are reconciled, the programs that appear in the source repository but not in the official inventory are the primary shadow application finding.
The application dependency mapping resolves the dynamic CALL problem: by tracing every CALL statement in every program, including dynamic calls where the program name is a variable, the dependency map identifies programs that are reachable from production processes even when they never appear in static scheduler inventories. A ghost program that is called dynamically by ten production programs appears in the dependency map even if it has no independent JCL job definition.
The JCL expansion capability traces the complete execution chain of every JCL job stream: resolving PROC references, expanding symbolic parameters, and building the full map of programs that each job invokes. When this map is compared against the official job schedule documentation, the jobs and programs that run in production without documentation coverage are surfaced automatically.
The impact analysis capability makes the discovery findings actionable: for every shadow program discovered, enumerate every production process that depends on it. A shadow program with no dependents is a dead code candidate, safe to retire. A shadow program with twenty production dependents is a critical undocumented asset that requires immediate governance attention. The impact scope is what determines remediation priority.
The enterprise search capability makes the complete inventory queryable: find every program that accesses a specific dataset (potential shadow data pipeline candidates), every program written after a specific date that has no CMDB entry (recent shadow applications), every program that writes to external file paths outside the standard data management hierarchy. This search capability supports both the initial discovery effort and the ongoing monitoring that prevents shadow application accumulation from resuming after the initial cleanup.
For organizations conducting legacy modernization programs, shadow application discovery is a prerequisite step. A modernization program that scopes migration based on the official application inventory and discovers shadow programs mid-execution is a modernization program whose scope, timeline, and budget were all wrong at the point of commitment. The discovery that should have happened before planning is now happening during execution, when its cost is highest.
The Governance Response: Not Blocking, But Visibility
The organizations that manage shadow IT effectively in 2026 have learned that blanket prohibition does not work and creates perverse incentives. Shadow IT reporting fails in most organizations for one reason: employees expect punishment. When a finance team member uses an unapproved expense tracker and self-reports it, a security team that responds with reprimand has trained that employee, and everyone they talk to, to stay silent next time.
The same principle applies to shadow application software. A developer who built a business-critical COBOL utility that the organization depends on should not be punished for not having gone through a governance process that may not have been clearly communicated at the time. The governance response to shadow application discovery should be:
Registration, not removal. Shadow programs discovered to be in the critical path of business processes are not shadow programs to be removed, they are undocumented production applications that require governance coverage. Register them, assign owners, assess their security posture, and treat them with the same governance discipline as any other production application.
Amnesty for self-disclosure. A governance program that creates safe channels for business units to disclose informal applications they have built surfaces shadow software faster than any technical discovery approach. The assurance that disclosure leads to governance support, help with documentation, security review, and formal registration, rather than disciplinary response removes the incentive for concealment.
Prevention through process. The root cause of shadow application accumulation is governance friction: the official process for requesting new application development is slower than the business problem requires. Reducing that friction, lightweight rapid development governance, embedded IT governance support in business units, streamlined approval for low-risk internal tools, reduces the rate of new shadow application creation without requiring ongoing technical discovery.
The Inventory You Think You Have Is Not the Inventory You Have
The difference between the application inventory that IT maintains and the application software that actually runs in enterprise environments is not a minor discrepancy. In large organizations with decades of application accumulation, the gap between documented and actual can approach thirty percent of total programs. The undocumented thirty percent includes programs that process sensitive data, perform regulatory compliance functions, sit in the critical path of business processes, and carry security vulnerabilities that nobody has reviewed because nobody knew to review them.
SaaS shadow IT discovery tools address the cloud layer of this problem well. The code-level shadow IT problem, the custom programs, ghost utilities, informal data pipelines, and undocumented batch jobs that populate enterprise legacy environments, requires a different approach: structural analysis of the actual software artifacts rather than monitoring of network traffic. The inventory that emerges from that analysis is often surprising in its completeness. The organizations that do this work consistently find that what they thought they had running in production and what actually runs are two meaningfully different things. Closing that gap is the foundation of every governance, security, BCP, and modernization program that depends on knowing what the organization actually operates.
