Business software security cannot be limited to applications considered strategic. In 2026, an AP-HP meal-ordering service exposed the identity data of 1,015 patients. The lesson is clear: a peripheral application can create a major risk as soon as it processes personal data, communicates with other systems, or remains accessible online.
What happened with AP-HP’s meal software?
AP-HP learned on September 24, 2026, that data from its meal-management software was being offered on a cybercriminal forum. On October 7, 2026, the institution confirmed that identity data concerning 1,015 patients had been published, while specifying that the investigation was ongoing.
The service in question allowed patients to select their meals during a hospital stay. It belonged to SRD Restauration, a Dedalus suite used by 23 AP-HP hospitals to manage nutrition, meal production, and distribution.
According to AP-HP’s October 7, 2026, statement, the published alorleged information included the last name, first name, birth information, and an internal patient identifier. As of that date, no medical, administrative, banking, or contact data appeared to be involved, subject to the investigation’s findings.
Claims circulated on the forum referred to more patients and certain professional accounts. On October 7, 2026, AP-HP stated that it had not verified these allegations. In the absence of a public technical rapport or a detailed statement from Dedalus regarding this incident as of October 10, 2026, attributing the intrusion to a specific vulnerability or actor would be premature.
AP-HP disabled the online module, reset passwords, and stated that it had corrected the suspected vulnerabilities. The institution had also filed a complaint on September 25, 2026, and then reported the incident to the Commission nationale de l’informatique et des libertés and the healthcare sector’s cyber support unit.
Why can a peripheral application expose a company?
A business application a device remains sensitive when it contains credentials, exchanges data via APIs, or provides access from the Internet. Business software security therefore depends on the actual data and connections, not on the “secondary” label assigned to the service in the organization.
Business software is an application designed to execute a process specific to an organization: orders, inventory, maintenance, human resources, production, or food service. It does not need to contain a complete medical record or a customer’s coord banking information to enable identity theft, fraudulent targeting, or pivoting to other systems.
The most common pitfall is organizational. A modest application may sometimes avoid the audits reserved for the main site, ERP, or customer relationship management software. Yet it retains old accounts, API secrets, administration interfaces, and technical dependencies that grow outdated.
In the projects we undertake, we often see a difference between the scope described in the specifications and the data exchanges actually added over the years. A precise specification of the business application must therefore catalog the flows, users, subcontractors, and retention periods, not just the expected screens.
What controls actually protect business software?
Business software security rests abord on ten controls: mapping data, reducing collection, assigning individual accounts, limiting privileges, verifying access, protecting APIs, logging operations, testing risks, segmenting the application, and preparing the incident response. No single tool can replace this set of measures.
The Commission nationale de l’informatique et des libertés recommends, in its 2024 security guide, inventorying processing activities, assigning individual accounts, and applying least privilege. Least privilege means giving each person or program only the permissions necessary for their role.
Access-rights reviews must be conducted at least once a year according to the CNIL’s 2024 guide. For an exposed application, frequent departures or sensitive data often justify a shorter interval. An annual review must not become a waiting period before deleting the account of a departed employee.
Here is the checklist to incorporate into design, maintenance, and audits:
- map the data, servers, providers, and dependencies;
- delete fields collected without a demonstrable purpose;
- use individual accounts and remove unnecessary permissions;
- review dorormant, shared, and technical accounts;
- enable multifactor authentication lors when the risk warrants it;
- review APIs and protect their keys, tokens, and passwords;
- record access and monitor abnorm behavior;
- conduct security tests prorportionate to the risks;
- segment the application to limit an attacker’s lateral movement;
- document incident management, notification, and communication procedures.
Multifactor authentication, or MFA, requires at least two distinct forms of proof to sign in, such as a password and approval on a device. The CNIL’s 2024–2025 recommendations consider it necessary in principle for sensitive databases or those likely to have a significant impact.
Honestly, adding MFA to the visible interface while leaving an old API protected by a shared secret mainly creates a false sense of security. Technical interfaces must be included in the audit, as must service accounts used automatically by software.
How should business software security be priorritized?
Business software security should be priorritized according to Internet exposure, data sensitivity, number of users, and connections to the information system. A peripheral application accessible online and connected to an identity repository deserves more controls than an isolated tool containing no personal data.
| Situation | Main risk | Priorritary controls | Recommended decision |
|---|---|---|---|
| Application accessible over the Internet | Unauthorized access | MFA, security testing, monitored logs | Address before production deployment |
| API connected to multiple systems | Data propagation and extraction | Protected secrets, least privilege, segmentation | Map every flow |
| Shared or dorormant accounts | Action cannot be attributed | Individual accounts, deletion, access-rights review | Corrrect without waiting for the annual audit |
| Sensitive personal data or data with a high imporct | Harm to individuals | MFA, appropriate encryption, protected logging | Conduct a risk assessment |
| Legacy and isolated application | Obsolete components | Corrective actions, version inventory, segmentation | Decide whether to maintain, redesign, or retire |
Segmentation consists of separating networks or systems so that a compromise does not provide access to the entire information system. The guides published by the Agence nationale de la sécurité des systèmes d’information since 2017 and the recommendations of the CNIL support this principle to limit an attacker’s lateral movement.
Maintenance matters just as much as design. A policy for automated management of corrective actions without disrupting production reduces the exposure time, provided that a test environment and rollback procedure are planned. When the budget is constrained, it is better to correct external access, excessive accounts, and exposed components first than to fund a sophisticated dashboard that is rarely monitored.
From the agency’s perspective, the reflex is to request proof that each control is working: an anonymized excerpt from an access-rights review, an alert generated by the logs, a tested restoration, or an account that was actually blocked. A written policy protects nothing if no one verifies its implementation.
What should you do after a data breach involving a business application?
After a breach originating from a business application, the company must contain access, preserve evidence, assess the data affected, and document the incident. A breach presenting a risk must be reported to the CNIL as soon as possible and, when feasible, within 72 hours under the RGPD.
All data breaches must be recorded, even when no external notification is required. When the risk to individuals is high, the General Data Protection Regulation also requires that they be informed promptly with clear explanations.
Is shutting down the entire system immediately always the right decision? Not necessarily. Disabling the system may limit exposure, but it may also erase volatile evidence or interrupt an essential service. The decision must involve business owners, the technical team, the data protection officer, and the people responsible for security.
Logs, meaning the history of access and actions, must be protected against modification and retained according to the level of risk. They help determine which accounts were used, which data was accessed, and how long the exposure may have lasted.
A incident response procedure suited to SMEs avoids improvising responsibilities under pressure. It must specify contacts, severity criteria, procedures for preserving evidence, shutdown decisions, and the notification process.
Defining the security of a business application before its development or takeover avoids many blind spots. An external perspective can be especially helpful in connecting business requirements, technical flows, and GDPR obligations without multiplying unnecessary controls.
FAQ on business application security
Is an application without banking data sensitive?
An application without banking data can still be sensitive if it contains identities, habits, health data, or access to other systems. Risk depends on the consequences for individuals and the company, not on a single data category.
How often should user permissions be reviewed?
In 2024, the CNIL recommends reviewing access permissions at least annually. However, rights must be revoked as soon as someone leaves or changes roles, and a high-risk application may warrant more frequent reviews.
Is two-factor authentication enough to secure an application?
Multifactor authentication reduces the risk associated with password theft, but it does not protect against a vulnerable API, excessive permissions, or an outdated component. Security requires several complementary barriers.
Should a penetration test be conducted before every launch?
A penetration test should be determined based on the risks, exposure, and scope of the changes. An Internet-accessible application that processes high-impact data or modifies its authentication warrants a thorough assessment before being deployed to production.