May 1, 2026 · By xhield.tech · 9 min read
Here's a scenario that plays out in Indian enterprises more often than anyone admits.
A marketing team, tired of waiting six weeks for IT to approve a file-sharing tool, signs up for a free Dropbox account and starts sharing campaign assets — including customer data — through it. A developer spins up an AWS instance on a personal card to test something quickly, meaning to shut it down in a week. It's still running eight months later, exposed to the internet, running an unpatched version of a web framework with three known CVEs. A sales team starts using a WhatsApp group to share leads, contracts, and client contact details because it's faster than the CRM.
None of this shows up in your annual VAPT report. None of it is in scope. Your pentesters tested what IT told them to test — and IT didn't know these assets existed.
Now imagine CERT-In knocks.
The Definition Nobody Wants to Say Out Loud
Shadow IT is technology — software, services, hardware, cloud instances — that employees and teams use without the knowledge or approval of central IT or security. It's not malicious. It's almost always well-intentioned people solving real problems with the tools available to them. That's precisely what makes it so pervasive and so hard to address.
The scale of it in modern enterprises is quietly staggering. Research consistently shows that the actual cloud footprint of a mid-sized enterprise is 3x to 5x larger than IT believes it to be. Every time a developer spins up a test server, a team adopts a new SaaS tool, or an employee creates a work account on a consumer platform, the attack surface grows — outside the visibility of security teams.
In India specifically, the acceleration of digital adoption post-pandemic, combined with the explosion of SaaS tooling available to teams on free or low-cost plans, has created a Shadow IT problem that most enterprises haven't caught up with yet.
Why CERT-In Makes This a Compliance Problem, Not Just a Security One
Before April 2022, Shadow IT was largely treated as a governance and risk management issue — serious, but manageable. CERT-In's directions changed the calculus entirely.
The critical point that many compliance teams are missing: CERT-In's reporting obligations apply to any breach affecting your organisation's data or systems, regardless of whether the affected asset was known to IT or formally in scope.
If a forgotten subdomain — set up by a developer two years ago and never decommissioned — gets compromised, and customer data is exfiltrated through it, that is a CERT-In reportable incident. The fact that it wasn't on your asset register doesn't exempt you. The fact that your last VAPT didn't test it doesn't exempt you. You have 6 hours to detect, characterise, and report it — for an asset you didn't know existed.
The 180-day log retention requirement compounds this. CERT-In requires logs from all ICT systems within your organisation's operational environment. Shadow IT assets — by definition outside managed infrastructure — are almost certainly not logging. Which means if a breach occurs through one of them, you not only have a detection gap, you have an evidence gap. That's a compounded compliance failure.
This is not a theoretical risk. Attackers actively target Shadow IT because they know it's the part of your infrastructure least likely to have WAFs, monitoring, updated patches, or access controls. It's low-hanging fruit — and it's outside the perimeter you're defending.
The Structural Problem With Annual VAPT Scope
A penetration test is only as good as the scope it operates within. And scope, in almost every enterprise, is defined by what IT knows about.
The process typically goes: security team asks IT for an asset list → IT provides the asset register → VAPT firm tests what's on the list. It's a reasonable process for a world where IT controlled everything. It's a broken process for a world where a product team can have a new microservice running in production by end of day without telling anyone.
This creates a structural blindspot that your annual VAPT cannot fix by design, because:
Scope is defined before testing begins. Whatever isn't on the list doesn't get tested. Shadow IT assets, almost by definition, aren't on the list.
Annual cadence misses continuous change. Even if you do a thorough job of discovering Shadow IT before your VAPT, the engagement captures a single point in time. New shadow assets created after the test are immediately outside any coverage.
Pentesters test, they don't discover. A VAPT firm's mandate is to assess the security of assets you give them, not to find assets you don't know about. Asset discovery is a pre-engagement activity — and most organisations treat it as a quick internal exercise rather than a rigorous external reconnaissance.
The result is a VAPT report that accurately describes the security of your known, managed infrastructure, while leaving an entirely separate attack surface unexamined.
What Attackers Already Know About Your Shadow IT
Here's the uncomfortable truth: an external attacker doing reconnaissance on your organisation will find your Shadow IT before your VAPT team does.
They're not constrained by your asset register. They query certificate transparency logs for every subdomain ever issued under your domain. They run passive DNS lookups against your IP ranges. They search Shodan and Censys for services responding on your ASN. They check S3 bucket naming conventions. They crawl job postings for technology references. They search GitHub for your domain name in committed code.
This reconnaissance takes hours, not days, with modern tooling. The result is a map of your actual attack surface — including the staging server your devops team forgot about, the API endpoint your engineering team exposed for testing, the employee file sharing service that never got shut down.
Your annual VAPT scope document has none of this. Your attacker does.
The information asymmetry between what an attacker can discover about your organisation and what your internal security team knows about your own organisation is one of the most underappreciated problems in enterprise security.
What Shadow IT Actually Looks Like in Indian Enterprises
It's worth being specific about the most common Shadow IT categories, because the term often conjures images of rogue hardware when the reality is far more mundane:
Forgotten cloud instances. Developers and engineers spin up cloud resources for testing, POCs, and temporary projects. Billing gets absorbed into broader cloud spend without scrutiny. These instances run indefinitely, often with permissive security groups, default credentials, or unpatched software.
Untracked subdomains. Marketing campaigns, product launches, regional sites, and developer environments create subdomains that outlive their original purpose. Certificate transparency logs make these permanently discoverable by anyone who looks.
Unauthorised SaaS adoption. Teams sign up for productivity tools, project management software, and communication platforms using corporate email, meaning the organisation has an account — and potentially corporate data — on a platform IT has never evaluated or approved.
Personal cloud storage for work files. The path of least resistance for sharing files that are too large for email. Customer data, contracts, and internal documents routinely end up in personal Dropbox, Google Drive, or OneDrive accounts.
Shadow APIs. Internal microservices, webhooks, and integration endpoints exposed to the internet for convenience, without going through security review or standard deployment processes.
What Actually Fixes This
Telling teams not to use Shadow IT doesn't work — the convenience gap that drives adoption doesn't disappear because of a policy. The answer is visibility, not prohibition.
Continuous external attack surface discovery. The only reliable way to find Shadow IT is to look for it the same way an attacker does — from the outside. Automated, continuous reconnaissance against your domains, IP ranges, and ASN that surfaces assets you didn't know existed. Not once a year, but as a persistent process that alerts you when something new appears.
Pre-VAPT scope validation. Before every VAPT engagement, run an external discovery sweep and compare results against your official asset register. The delta — assets found externally but not in your register — is your Shadow IT problem quantified. Add it to scope before the test, not after.
Change alerting, not just periodic reporting. Shadow IT isn't a static problem. A new asset can appear today. Monitoring that tells you within 24 hours that a new subdomain has appeared, or a new service is responding on your IP range, is fundamentally more useful than a quarterly report.
Tie discovery to CERT-In reporting readiness. Audit your logging coverage against discovered assets, not just registered ones. If a shadow asset is breached and you have no logs from it, you have a 6-hour reporting obligation and no evidence to characterise the incident. Logging coverage should follow the actual attack surface, not the asset register.
The Question Worth Sitting With
If someone with a few hours and access to public OSINT tools mapped your organisation's external attack surface right now — every subdomain, every exposed service, every cloud asset responding on your IP ranges — how different would that map look from your VAPT scope document?
For most Indian enterprises, the answer is: significantly different.
That gap is your Shadow IT problem. It's also where your next breach is most likely to start. And under CERT-In, it's where your next compliance failure is hiding.
The good news is that the same techniques attackers use to find Shadow IT can be turned inward, as a continuous defensive process. The question is whether you find it first.
At xhield.tech, we're building AI-powered attack surface intelligence that discovers what you have exposed — not just what you think you have. If you're preparing for a VAPT engagement or trying to get your CERT-In compliance posture right, we'd like to talk.
Tags: Shadow IT CERT-In VAPT Attack Surface Management Enterprise Security India Cybersecurity CISO Cloud Security Asset Discovery