Spanish energy companies have recently been under scrutiny because of customer-data incidents involving companies such as Endesa, Naturgy, and Iberdrola's commercial ecosystem.
The situation is important because it highlights a common weakness in large organizations: the most sensitive risk does not always sit inside the most obvious systems.
When people think about cybersecurity in the energy sector, they often imagine power plants, substations, grid control rooms, and industrial networks. Those areas are extremely important, of course. But recent incidents appear to point toward another major risk area: the commercial and customer-data environment around energy providers.
That includes customer portals, sales partners, outsourced providers, call centers, CRM platforms, onboarding tools, billing-support systems, reporting dashboards, and third-party databases.
These systems may sit outside the most protected operational environments, but they often contain the information criminals want most.
What Is Happening?
Attackers are targeting systems that store or process customer information.
That data can include full names, DNI/NIF numbers, email addresses, phone numbers, home addresses, CUPS codes, contract details, tariff information, payment method data, and in some cases banking-related information.
This kind of data has real value. Criminals can use it for phishing, fake invoices, impersonation, fraudulent contract changes, identity theft, and resale on underground markets.
A customer-data incident can be serious even when there is no impact on electricity delivery. If an attacker knows someone's energy provider, address, contract details, and payment method, they can create a very convincing scam.
For example, a customer might receive a fake message saying there is a problem with their electricity bill or that their contract needs to be updated. If that message includes real personal or contract information, many people will believe it.
That is why these incidents matter. The immediate risk for customers is often fraud, social engineering, and identity abuse.
Why Energy Companies Are Attractive Targets
Energy companies are attractive to attackers because they combine three things criminals look for.
First, they have very large customer bases. A successful breach can expose a significant number of records.
Second, they hold sensitive identity and contract data. Energy accounts are connected to real people, real addresses, payment details, and regulated services.
Third, they depend on large supplier ecosystems. Major utilities do not do everything internally. They work with sales agencies, software vendors, call centers, billing providers, marketing partners, customer-support providers, SaaS platforms, and subcontractors.
Every partner that stores or accesses customer data becomes part of the security perimeter, even if the main company does not fully control that partner's systems.
That is where the problem becomes difficult. An attacker does not always need to compromise the strongest part of the organization. They may only need to find a weaker partner with access to valuable data.
The Commercial Layer Deserves More Attention
Many energy companies invest heavily in protecting core infrastructure. That makes sense. Operational technology, industrial systems, and grid-related environments need strict controls.
But customer-data platforms also deserve serious attention.
The commercial layer can include customer relationship management systems, sales platforms, customer support portals, third-party databases, marketing systems, contract-signing platforms, document storage, data exports, reporting dashboards, call-center tools, and partner APIs.
These systems may be treated as normal business tools, but from an attacker's perspective they can be extremely valuable. A weak CRM, a poorly protected supplier portal, or an overprivileged sales-agent account can lead to a large data leak.
That is why security teams need to follow the data, not only the infrastructure diagram.
Where Pentesting Often Falls Short
Penetration testing is supposed to help organizations find weaknesses before attackers do. The problem is that pentests are often limited by scope, time, access, legal boundaries, and business concerns.
In many cases, the company may have done a pentest, but the test may not have covered the systems that created the real risk.
A traditional pentest may focus on the public website, the customer login page, a mobile app, a small set of APIs, basic cloud exposure, known vulnerabilities, and OWASP Top 10 issues.
Those areas are important, but they may not show the full attack path. A realistic attacker may look somewhere else: supplier portals, sales-agent accounts, old CRM exports, staging databases, forgotten admin panels, misconfigured storage buckets, leaked API keys, SFTP servers, subcontractor tools, shared spreadsheets, and weak reporting dashboards.
If these systems are outside the scope, the final report can look reassuring while important risks remain untouched.
The Better Pentest Question
A useful pentest should ask more than whether a system has vulnerabilities.
It should ask whether a realistic attacker can reach sensitive customer data.
That changes the nature of the test. Instead of only checking for technical flaws, testers should simulate realistic scenarios:
- A supplier employee gets phished
- A sales-agent account is compromised
- An API key leaks from a developer machine
- A CRM export is exposed
- A subcontractor system is breached
- A reporting dashboard is accessed from an unusual location
- A partner account starts scraping customer records
- A former employee account still works
The goal is to understand whether one weak point can turn into a mass data exposure.
Credential Abuse Should Be Taken Seriously
Many breaches do not begin with a dramatic technical exploit. They begin with credential abuse.
That can mean stolen usernames and passwords, phished supplier accounts, reused passwords, weak or missing MFA, compromised sessions, leaked API tokens, shared accounts, or dormant accounts that were never disabled.
If a breach is caused by credential abuse at a partner, the main company still has a responsibility to learn from it.
A supplier that handles sensitive customer data should be expected to protect credentials properly. That means strong MFA, secure password policies, monitoring for suspicious logins, fast account revocation, least-privilege access, and clear controls around exports and data access.
Energy companies should be stricter about which partners they accept into their ecosystem. A partner should not be trusted with DNI/NIF numbers, contract details, CUPS codes, or banking-related data unless they can prove they protect that data properly.
If a partner cannot protect credentials, monitor access, and control data exports, they should not have broad access to customer information.
Common Pentest Mistakes in These Environments
1. The Scope Is Too Narrow
A pentest may only cover systems directly owned by the main company. Supplier systems, commercial partner platforms, call-center tools, and subcontractor environments may be excluded.
That creates a dangerous blind spot. If a third party stores or processes customer data, that third party belongs in the security assessment.
2. Bulk Export Abuse Is Not Tested Properly
A platform may work exactly as designed and still be risky. For example, a sales agent may be allowed to search customer records. That may be necessary for their job. But can that same account export thousands of records? Can it scrape data through an API? Can it download CSV files without approval?
Pentests should test whether users can extract abnormal volumes of data through normal features. The issue is not only whether access exists. The issue is whether the access is limited, monitored, and justified.
3. Authorization Testing Is Too Shallow
Broken access control is one of the most dangerous weaknesses in customer-data systems. Examples include one agent seeing customers they do not manage, one partner accessing another partner's records, users changing IDs in URLs to view other records, APIs returning too much information, admin functions being available to normal users, former employees still having active accounts, and support roles having broader access than needed.
Authorization testing takes time. It can be repetitive and less glamorous than finding a high-profile exploit. But for customer-data platforms, it is one of the most important parts of the test.
4. Supplier Pentest Reports Are Accepted Too Easily
A supplier may send a pentest summary that says there were no critical findings. That summary may not be enough.
The report may be old. It may exclude the exact system holding customer data. It may exclude APIs, cloud storage, staging systems, subcontractors, or export functionality. It may hide unresolved medium-risk findings that are very relevant in context.
Energy companies should not accept vague security summaries for systems that process sensitive data. They need to understand what was tested, who tested it, when it was tested, what was excluded, what findings remain open, whether fixes were retested, and whether customer-data access was actually assessed.
5. Credential-Abuse Scenarios Are Excluded
Many pentests avoid phishing, stolen-session testing, password-reset abuse, MFA weakness testing, or compromised-account scenarios. That makes the test less realistic.
Attackers often start with valid credentials. A serious assessment should test what happens after those credentials are compromised: what can a low-privilege supplier account access? Can the account export data? Is MFA required? Are suspicious logins detected? Are old accounts disabled?
A system can resist direct exploitation and still fail badly when a valid account is abused.
6. Staging, Backups, and Old Data Are Ignored
Customer data often leaks from places that were never meant to be public or permanent. These can include test databases, staging systems, backup folders, old exports, developer environments, logs, data lakes, analytics tools, temporary files, and shared drives.
A production application may be well protected while an old copy of the same data sits in a weaker environment. Pentesting should follow the data across the whole lifecycle.
Critical Systems Should Be Tested by Different People
Critical systems should not always be tested by the same people, the same vendor, or the same internal team.
Different testers bring different assumptions, techniques, and blind spots. For high-risk environments, companies should rotate or combine testing approaches using internal security teams, external pentest firms, red teams, cloud specialists, API security specialists, identity and access specialists, OT-aware testers, source-code reviewers, detection engineers, and privacy and data-flow reviewers.
This matters because one team may be excellent at web application testing but weaker at cloud misconfigurations. Another may be strong in Active Directory but not in API authorization. Another may find business-logic flaws that automated tools miss.
For critical systems and sensitive customer-data environments, relying on one familiar testing team year after year can create blind spots. Fresh eyes are valuable. In security, they are often necessary.
The Restraints That Make This Difficult
It is easy to say companies should test everything. In reality, critical sectors face real restraints.
Operational Sensitivity: Some systems support billing, customer service, contract changes, and regulated processes. Aggressive testing can disrupt operations if it is not planned carefully.
Legal Boundaries: The main company may not have direct permission to test a supplier's systems, even when that supplier holds customer data. This is why security requirements need to be written into contracts before the relationship begins.
Privacy Requirements: Testing systems that contain real customer data creates privacy obligations. Testers need strict rules, anonymization where possible, secure evidence handling, limited access, and clear legal approval.
Supplier Resistance: Some suppliers may resist deep testing. They may say it is disruptive, confidential, outside the contract, or already covered by their own audit. That resistance creates risk when the supplier handles sensitive data.
Time and Budget: Realistic testing takes time. Threat-led pentesting, authorization testing, supplier validation, and retesting require skilled people and proper planning. A quick annual test cannot cover a large utility ecosystem properly.
Fragmented Ownership: Customer data may be spread across internal teams, outsourced providers, SaaS tools, subcontractors, and legacy platforms. Sometimes nobody has a complete map of where the data lives.
Fear of Expensive Findings: There is also a human factor. Broad testing can reveal problems that are expensive to fix. Some organizations quietly keep the scope narrow because wider testing creates difficult conversations. Security problems do not disappear because they were excluded from scope.
What Energy Companies Should Do Differently
1. Hire More Skilled Testers
Large energy companies need enough testers to match the size and complexity of their real attack surface. They need different types of expertise: web application testers, API security testers, cloud security testers, identity and access specialists, Active Directory testers, red team operators, OT-aware security professionals, source-code reviewers, detection engineers, third-party risk specialists, and privacy and data-flow analysts.
More testers allow for broader coverage, deeper testing, more frequent assessments, and better retesting. But hiring more testers only helps if they are given authority to challenge scope, review supplier evidence, test realistic attack paths, and push for fixes.
2. Make Third-Party Testing a Contractual Requirement
If a supplier handles sensitive customer data, testing rights should be part of the contract. That should include right to audit, right to request pentest evidence, right to test relevant systems, mandatory MFA, minimum logging requirements, data-retention limits, breach notification timelines, subcontractor approval, encryption requirements, vulnerability remediation deadlines, and retesting obligations.
A supplier should not be able to hold sensitive data while refusing meaningful security validation.
3. Use Threat-Led Pentesting
Testing should be based on realistic scenarios: a supplier account is phished, a sales-agent laptop is compromised, a CRM API key leaks, a reporting dashboard is exposed, a subcontractor has weak MFA, a partner user tries to export all assigned customers, a former employee account is still active.
These scenarios help companies understand whether a small failure can become a serious breach.
4. Test Authorization Deeply
Companies should test whether users can access records outside their role, whether partners can view each other's customers, whether APIs expose hidden fields, whether admin functions are reachable by normal users, whether old accounts still work, whether roles are too broad, whether export permissions are excessive, and whether support users can access more data than needed.
5. Follow the Data
Security teams should map where sensitive customer data lives across main databases, CRM systems, supplier platforms, backups, staging environments, data warehouses, logs, BI tools, shared folders, export files, call-center platforms, SaaS tools, and subcontractor systems.
The company should constantly ask whether each system really needs the data it holds. If the answer is no, the data should be removed, masked, tokenized, anonymized, or restricted.
6. Reduce Bulk Export Risk
Bulk exports should be treated as high-risk actions. Controls should include limiting export permissions, requiring approval for large exports, logging every export, alerting on unusual volumes, blocking repeated scraping, rate-limiting sensitive APIs, requiring MFA for exports, and watermarking exported files.
No low-level account should be able to quietly download a large customer dataset.
7. Improve Credential Security Across Partners
Suppliers should be expected to use strong MFA, unique named accounts, no shared credentials, secure password policies, fast offboarding, device security, session protection, suspicious login monitoring, least-privilege access, API token management, and regular access reviews.
Energy companies should verify these controls instead of simply asking whether they exist. For sensitive data, trust needs evidence.
8. Retest Fixes Properly
A pentest does not end when the report is delivered. The process should continue until findings are fixed, fixes are retested, similar systems are checked, risk owners understand what remains, compensating controls are validated, and lessons are added to future testing.
Many organizations collect reports but do not close the loop. That weakens the value of testing.
9. Build Continuous Testing
Annual pentests are not enough for large, changing environments. Companies should combine pentesting with continuous vulnerability scanning, attack-surface monitoring, cloud configuration reviews, API testing, identity reviews, supplier reassessments, detection testing, purple-team exercises, tabletop breach simulations, and vulnerability disclosure programs.
10. Test Detection and Response
Pentesting should also check whether suspicious behavior is noticed. Does anyone detect thousands of customer records being queried? Does a large export trigger an alert? Are supplier accounts monitored? Are logins from unusual locations reviewed? Are dormant accounts flagged?
Prevention matters, but detection matters too. A breach becomes much worse when nobody notices until the data appears online.
11. Hire Different Types of Specialist Pentesters
Not all pentesters are the same, and energy companies should resist the temptation to hire generalists for every engagement.
A web application tester is not automatically the right person to assess an OT environment. A network penetration tester may not have the depth needed for OAuth abuse, IDOR chains, or API authorization logic. A cloud security specialist may not think about social engineering the same way a red team operator does.
The types of specialists that energy companies and their suppliers should consider include:
- OT/ICS security specialists who understand industrial control systems, SCADA environments, and the safety implications of testing in live operational environments
- Social engineering and phishing specialists who can simulate realistic supplier and employee compromise scenarios
- OSINT and reconnaissance specialists who map the attack surface from the outside, the same way an attacker would before touching anything
- API security specialists who focus on broken object-level authorization, mass assignment, excessive data exposure, and rate-limiting gaps
- Identity and access management specialists who look specifically at role definitions, privilege creep, account lifecycle, MFA gaps, and session management
- Cloud security specialists focused on misconfigured storage, overpermissioned service accounts, and insecure infrastructure-as-code
- Supply chain and third-party risk testers who specifically assess vendor access, partner portals, and the weakest points in the ecosystem
- Purple team operators who work alongside detection engineers to test whether monitoring actually works in practice
Rotating between different specialist types also prevents the comfortable familiarity that builds up when the same firm tests the same scope year after year. A fresh specialist in a specific domain will often find what the regular team has normalized into blindness.
12. Invest in the Spanish Cybersecurity Startup Ecosystem
This point goes beyond energy companies specifically, but it is directly relevant to why Spain's resilience against these kinds of incidents is weaker than it should be.
The Spanish cybersecurity startup ecosystem is falling behind. Investment is slow. Talent is scarce. And some of the institutional money that should be going toward building serious cybersecurity companies is going elsewhere.
A recent example that drew attention: a well-known institution was seen promoting a health-related card game with funding that many in the community felt should have been directed toward supporting cybersecurity startups and building Spain's technical security capacity. That kind of misallocation is not an isolated event. It reflects a broader pattern of institutional indifference toward cybersecurity as an economic and strategic priority.
This matters for energy companies because the security of the sector depends partly on the quality of the talent pool, the tools available, and the maturity of the local security industry.
When there is not enough investment in domestic cybersecurity startups, several things happen: the best talent leaves for higher salaries abroad, innovative tools get built in other markets, local companies have fewer specialized options to work with, and the overall security culture stagnates.
Spain has the talent and the technical foundation to build a strong cybersecurity ecosystem. What is missing is consistent, serious investment directed at the right places. Energy companies, large enterprises, and public institutions all have a role to play in changing that, whether through procurement decisions that favor innovative domestic vendors, partnerships with cybersecurity accelerators, participation in talent pipelines, or direct investment in early-stage security companies.
A sector that gets breached repeatedly through weak supplier ecosystems should also be asking a harder question: what are we doing to build the security industry that will protect us in the future?
Why Hiring More Testers Is Part of the Solution
A large energy company may have multiple customer portals, mobile apps, internal admin tools, APIs, cloud environments, supplier integrations, data warehouses, call centers, commercial partners, legacy systems, identity platforms, and thousands of vendor users.
That environment cannot be tested properly by a tiny team once or twice a year.
More testers mean more coverage. More coverage means fewer blind spots. It also allows the company to separate duties better: one group tests applications, another tests cloud infrastructure, another reviews identity controls, another validates detection, another focuses on suppliers, another tests critical systems independently.
Different testers find different weaknesses. For critical environments, this diversity matters.
What a Better Security Program Looks Like
A mature program would include several layers.
Baseline testing for common vulnerabilities across websites, apps, APIs, and cloud environments.
Threat-led testing focused on realistic attacker paths, especially supplier compromise and customer-data exposure.
Authorization testing across roles, partners, agents, administrators, and APIs.
Data-flow testing to understand where sensitive data is stored, copied, exported, and retained.
Supplier validation with real security evidence, not only questionnaires.
Credential-abuse testing to understand what happens when a partner account is compromised.
Independent testing for critical systems using different testers and specialized teams.
Detection testing to verify that suspicious access, scraping, exports, and login abuse are noticed.
Retesting to confirm that fixes actually work.
Continuous monitoring to catch new exposures between formal assessments.
The Main Lesson
The recent Spanish energy incidents are a reminder that customer-data security depends on the whole ecosystem. The main company, its suppliers, its commercial partners, its call centers, its SaaS providers, and its subcontractors all influence the final risk.
Attackers will look for the easiest path to valuable data. Sometimes that path is a supplier account. Sometimes it is an old database. Sometimes it is an API. Sometimes it is an export feature nobody reviewed carefully enough.
The lesson for security teams is clear: expand the scope, include third parties, test credential-abuse scenarios, follow the data, test bulk export controls, test authorization deeply, use different testers for critical systems, hire enough skilled people, demand stronger controls from partners, retest fixes, improve detection, and reduce unnecessary data sharing.
The goal should be simple: make it much harder for one weak account, one weak partner, or one forgotten system to expose thousands of customers.