An ITIL 4 Analysis of Public Database Risks

Lessons from MongoDB, EY, and Toyota

When a Single Checkbox Destroys Reputation

Imagine this: your data engineer is pressed for time. They are tasked with transferring a 16 TB database to the cloud to ensure quicker backups. In their haste, they forget to uncheck one single box “Allow Public Access” remains checked.

That’s all it takes. One click.

Within hours, 4.3 billion professional profiles (names, emails, and job histories) are available for anyone on the internet to download. No Password. No Firewall.

This occurrence isn’t a science fiction. In November 2025, cybersecurity experts discovered just that a massive MongoDB database, completely exposed. This instance is not a standalone error; it reflects a larger issue within risk management practices.

In this article, we will dissect the Public Database crisis through the framework of ITIL 4 . The world’s most adopted IT service management framework. We will explore why antivirus is not enough, and how your organization can avoid becoming the next headline.

Picture 1. Public databases are often referred to as low-hanging fruit for attackers | Source: Unsplash

Why ITIL 4? Because Risk is Not Just Technical

Before we dissect the failures, let us briefly revisit ITIL 4. ITIL 4 (short for Information Technology Infrastructure Library, version 4) is the world’s most widely adopted framework for IT service management. Think of it as the operating manual for how IT should deliver value to a reliably, securely, and efficiently.

Unlike technical checklists, ITIL 4 focuses on practices, likely repeatable, measurable ways of working.

But, When a database becomes public, it is rarely because hackers are geniuses. It is because someone skipped a step and ITIL 4 exists to make skipping steps impossible.

Picture 2. Flow diagram of ITIL 4 Service Value System (SVS)

Source: Axelos, ITIL 4 service value chain (2019)

The 2025 Public Database Emergency

Why is this topic urgent? Because the numbers are terrifying.

1. The Mega-Leak: MongoDB — 4.3 Billion Records

In late 2025, researchers came across a MongoDB server that had no password protection whatsoever. Its size? 16.14 terabytes. Inside were billions of personal records scraped from LinkedIn and Apollo.io. Includes names, emails, job histories. For cybercriminals, this was not just data; it was a ready-to-use arsenal for social engineering and AI-powered fraud.

2. The King of Accounting Stumbles: EY (Ernst & Young)

Then came October 2025. Ernst & Young, one of the world’s Big Four consulting firms, and a company that literally sells cybersecurity advice left a 4 TB SQL Server backup file exposed on Microsoft Azure. The irony was hard to miss. The lesson, however, was crystal clear: no organization, regardless of budget or reputation, is immune to cloud misconfiguration.

3. The Worsening Epidemic

And the problem is accelerating. Gartner predicted that by 2025, a staggering 99% of cloud security failures would be the customer’s own fault, usually due to simple misconfigurations. Around the same time, OWASP updated its famous Top 10 list. Security misconfiguration jumped from the fifth spot (in 2021) all the way to number two in 2025. That is how fast this issue has grown.

Picture 3. A chart to showing that 99% of cloud security failures are caused by human error.

Two Lenses — OWASP vs. ITIL 4

To solve the problem, we can use two different analytical frameworks.

ITIL 4 connects directly to public database risks through three core practices:

1. Risk Management — Identifying and controlling events that could harm business value. If “database becomes publicly accessible” is not in your risk register, you are blind.
2. Service Configuration Management (SCM) — Every cloud asset must be a Configuration Item (CI) with accurate metadata (owner, location, access rules). A healthy CMDB is an early warning system.
3. Change Enablement — Any change to access control lists (ACLs), firewalls, or authentication settings must go through a Standard Change with risk assessment and rollback plan.

Picture 4. illustrating the relationship between three ITIL 4 practices (Risk Management, SCM, Change Enablement) and public database incidents.

Case Studies — When ITIL 4 Practices Fail

Let’s analyze three real-world incidents:

1. MongoDB (2025) — 16TB of Professional Data Exposed

In November 2025, security researcher Bob Diachenko stumbled upon a MongoDB instance that had no access restrictions. What he found inside was staggering: 4.3 billion individual records , likes names, email addresses, LinkedIn profiles, and job histories. The whole database came in at 16.14 terabytes.

So, what went wrong when we look at it through the ITIL 4 lens?

• Service Configuration Management (SCM): This database was never recorded as a Configuration Item (CI) in any CMDB. In simple terms, no one knew it existed in that state. And if you do not know an asset exists, you certainly cannot protect it.
• Risk Management: The possibility of “database authentication being disabled” was never identified as a risk in the first place. It never made it into the risk register. That means no one ever thought about what could go wrong.
• Incident Management: When the authentication setting switched from “secure” to “open,” there was no automated alert. No alarm bells rang. The team found out only when a researcher reported it — far too late.

Picture 5. Visual representation of the MongoDB incident involving a 16TB data leak.

Source: Security Affairs, December 2025.

2. Ernst & Young (EY) — October 2025: When a Big Four Firm Trips

EY, one of the world’s largest professional services networks, made an embarrassing mistake. They left a 4 TB SQL Server backup file exposed on Microsoft Azure. That file contained credentials, API keys, and internal documents , exactly the kind of information attackers dream of.

Where did the process break down?

• Change Enablement (or rather, the lack of it): During a cloud migration, someone made a simple ACL (Access Control List) change. But no one followed the Standard Change procedure. There was no risk assessment, no peer review, no second pair of eyes.
• Service Validation and Testing: After the backup file was deployed, no one tested whether it was publicly accessible. A basic check would have caught the problem immediately.

The irony is almost painful: EY is a cybersecurity consultant. They sell security advice to other companies. Yet here they were, making a mistake that any well-run change management process would have prevented. The lesson? No organization is perfect. Process failures can happen anywhere.

Get Eka Saputra’s stories in your inbox

Join Medium for free to get updates from this writer.

Remember me for faster sign in

Source: Neo Security / Security Affairs, October 2025.

3. Toyota (2013–2025): A Decade of Exposure

Here is perhaps the most surprising case. Toyota exposed the location data of more than 2 million connected cars for ten full years. From 2013 to 2023, a misconfigured database sat open to the public. No one noticed. For a decade.

What went wrong from an ITIL perspective?

• Continual Improvement: This is supposed to be a core ITIL practice. But Toyota apparently had no regular audits or configuration reviews. If they had run even an annual scan, they would have found the problem in 2014, not 2024.
• Problem Management: The root cause was never properly investigated. The underlying issue — a lack of automated configuration scanning — was never identified. So the same mistake just continued year after year.

Source: Varutra / Threatpost, 2023.

Pros & Cons of ITIL 4 for Public Database Risk Management

ITIL 4 holds significant strength, yet it is not a cure-all solution. This is a straightforward evaluation.

THE PROS (Why ITIL 4 Adds Value)

1. It provides an auditable trail for compliance and legal defense.

When authorities or auditors require proof of risk evaluation before a security incident, the documentation provided by ITIL 4 offers a straightforward reply: “Indeed, the risk was recognized, evaluated, and sanctioned — here is the documented proof”. This can notably diminish legal risks and regulatory penalties.

2. It eliminates barriers between security and operational functions.

Numerous security solutions function separately. ITIL 4 unifies Risk Management with Change Enablement and Service Configuration Management. An alteration to a database Access Control List promptly refreshes the risk register and notifies the appropriate teams. No longer will there be claims of “I was unaware that change occurred”.

3. It transforms reactive solutions into proactive enhancements.

Following an event (like the EY incident), ITIL 4’s Problem Management framework analyzes the underlying cause and executes lasting corrective measures. The same error in configuration will not occur again throughout the organization.

THE CONS (Where ITIL 4 Presents Challenges)

1. It may create additional process burdens.

For entities that release code several times daily, stringent workflows for change approval could delay the pace of delivery. ITIL 4 emphasizes control rather than speed, which can clash with agile or DevOps methodologies unless adjusted thoughtfully.

2. It necessitates continuous commitment, not merely tools.

Acquiring a costly configuration management database or IT service management system does not ensure effective outcomes. In the absence of regular updates, assignment of responsibilities, and ongoing reviews, the configuration database can become obsolete and ineffective. ITIL 4 struggles when there is a breakdown in human discipline.

3. It demands a significant financial commitment.

Training personnel, engaging consultants, and deploying compliant tools can easily surpass $50,000 for a medium-sized organization. For very small teams or startups with limited budgets, such an investment is challenging to rationalize.

Adopting ITIL 4 for database risk management delivers three concrete business benefits.

1. Avoid Financial & Regulatory Disasters

• Cost of downtime: In Australia, IT downtime costs $7,011 per minute (source: ITSM.tools, 2025). One exposed database can lead to hours of downtime, plus legal fines.
• Regulatory compliance: Indonesia’s PDP Law (UU No 27/2022) imposes administrative fines up to 2% of annual revenue for data breaches caused by negligence. ITIL 4’s documented processes serve as evidence of due diligence.

2. Turn Security into a Competitive Advantage

• Clients and partners increasingly ask for auditable risk management frameworks. A company that follows ITIL 4 can demonstrate maturity.
• In tenders, having ITIL-based processes can be a differentiator, especially in finance, healthcare, and government sectors.

3. Optimize Cloud Spending

• A well-maintained CMDB does more than track security — it also reveals zombie resources (databases, storage buckets, VMs) that are still running but no longer used.
• One organization found $50,000/month in unnecessary cloud costs after cleaning up untracked CIs.

References

1. AXELOS. (2020). ITIL Foundation: ITIL 4 Edition. TSO.
2. AXELOS. (2020). ITIL 4: Direct, Plan and Improve. TSO.
3. Gartner. (2024). Gartner Predicts 99% of Cloud Security Failures Will Be the Customer’s Fault by 2025.
4. OWASP. (2025). OWASP Top 10 — A02:2025 — Security Misconfiguration.
5. Wiz. (2025). Cloud Data Security Snapshot: Current Exposure Trends Report 2025.
6. Security Affairs. (2025, Dec 14). Experts found an unsecured 16TB database containing 4.3B professional records.
7. Security Affairs. (2025, Oct 31). Ernst & Young Exposes 4TB SQL Server Backup Publicly on Microsoft Azure.
8. The Register. (2025, Oct 29). EY exposed 4TB SQL backup file to open web, researchers say.
9. SC World. (2025, Oct 30). Extensive EY SQL Server backup file inadvertently exposed.
10. NordPass. (2026). A new trend in data leaks: Fewer incidents, greater exposure.
11. IronCore Labs. (2025). One Unchecked Box, One Billion Records: The Human Error Problem.
12. Security Boulevard. (2025). Top Cloud Security Challenges Businesses Face in 2025.