‘It’s just an internal system’ – the exemption that leaves the inside exposed
No input validation, no logging, a shared admin password. It’s only internal, after all. The sentence gets used as an exemption from everything we know about security, and it rests on an assumption that stopped being true a long time ago: that the inside is safe.
The exemption
Notice how often the sentence gets used, and what it gets used for:
“We’re skipping input validation here, it’s just internal.”
“Everyone uses the same admin account, it’s just internal.”
“No point in audit logging, it’s just internal.”
The sentence works as a universal exemption: everything we know about security, canceled by one word. And the exemption rests on a single assumption:
That there is an inside, and that the inside is safe.
Both were doubtful ten years ago. Today both are wrong.
The inside no longer exists
Draw “the internal system” and look at what actually reaches it:
Home-office laptops on home networks. VPN access for consultants, some of it forgotten and still active after the engagement ended. SaaS integrations with API keys. CI/CD pipelines with broad permissions. And every single developer machine with hundreds of third-party packages carrying their own update channels.
“Internal” no longer describes a safe zone. It only describes who the system was meant for. Attackers don’t care about intentions. They care about ways in, and about what waits inside. And the exemption leaves traces. GitGuardian found in 2026 that internal repositories are about six times as likely as public ones to hold hardcoded secrets, calls it the debt of private-by-default thinking, and describes that buildup as the material attackers exploit once they reach internal systems. Around 28 percent of the leaks they recorded started entirely outside the code, in Slack, Jira and Confluence.
One phished developer account, and the attacker is standing on the inside. Then the question is brutally simple: what meets them there? The systems built with validation, least privilege and logging, or the systems built with the exemption?
Internal systems are often the most dangerous
Flip the perspective, and you see that internal systems deserve more suspicion, not less:
- They have broader access: admin tools, data exports, integration keys
- They often get the least security attention, and easily fall outside the scope the pentest was bought for
- They often log the least, and a break-in nobody logs is found late. In Mandiant’s 2025 investigations, 48 percent of intrusions were first detected from outside (M-Trends 2026)
- And they were built with the exemption, so they fall easiest
The internal customer admin tool with access to every customer is a better prize than the hardened public API. Attackers know that. The exemption sentence makes sure the defenders don’t.
Swap the exemption for one question
The principle that replaces “it’s just internal” is well known: assume the network is hostile, verify every request, grant the least access necessary. Zero trust, if you want the term.
But terms implement nothing. Start with the question instead. Put it into design discussions and PR templates:
“What can an attacker who is already standing here do next?”
The question accepts the premise the exemption denies: that the inside can fall. And it forces the right measures, one system at a time: validation at every boundary, separate accounts with separate permissions, logging that makes movement visible.
The point isn’t that every internal system has to be turned into a fortress overnight, but that the exemption has to go, and every deviation from the standard has to be a considered decision, not a reflex (in Norwegian).
When nobody asks the next question
“It’s just an internal system” was once a description.
Now it’s a vulnerability with grammar.
Strike the sentence from the team’s vocabulary and ask the attacker question instead. Your inside is only as safe as the weakest system somebody excused with one word.