Who can see your customers’ data? Data security in custom software development

01How data actually leaks

Verizon’s 2026 Data Breach Investigations Report has the numbers. Exploiting vulnerabilities is now the most common way attackers get in, at 31% of breaches with a known entry point, ahead of stolen credentials at 13%. A third party was involved in 48% of breaches, up 60% on the previous year. And the human element, from clicking a phishing link to sending data to the wrong person, played a part in 62%.

Regulators see the same pattern. The CMS GDPR Enforcement Tracker lists 3,275 fines totaling 7.16 billion EUR as of September 2026. Insufficient technical and organizational measures to protect data account for 616 of them and almost 972 million EUR. Article 32, the GDPR’s security article, is the third most cited in fines overall.

Security is not only about attackers, either. According to Eurostat, 21.5% of EU companies with at least 10 employees had a security incident with real consequences in 2023. The most common one was services going down because of a hardware or software failure (18.0% of companies), far ahead of outages caused by outside attacks (3.4%). Backups and the ability to restore a system quickly matter as much as keeping intruders out.

02Security is decided at every stage of the project

Article 25 of the GDPR requires data protection to be built in at the time the means of processing are decided, which in practice means when the system is being designed. The European Data Protection Board’s guidelines on Article 25 explicitly list procurement, outsourcing, development, testing, maintenance and deletion. Each stage of a project comes with its own security tasks.

You can see how our own projects run, from the first call to handover, on our How it works page.

03Start with a data inventory, not with code

Before the first screen is designed, list every piece of data the system will store. Each item needs three answers: why we need it, how long we keep it and who is allowed to see it. The GDPR calls this data minimization. Data you never collect cannot leak.

Deletion matters just as much. When a customer leaves or a legal retention period ends, the data should be deleted or irreversibly anonymized. The EDPB reminds controllers that they must decide which personal data they need, and for how long, in backups and logs too. Put deletion in the brief as a feature of its own, such as a nightly job that sweeps old records.

If the system is likely to pose a high risk to people, for example by processing special category data on a large scale or by systematic monitoring, Article 35 of the GDPR requires a data protection impact assessment before it goes live. Find that out when writing the brief, not a week before launch.

04Who can access what: roles, permissions and two-factor authentication

Broken access control tops the OWASP Top 10:2025 list of web application security risks, and testers found some form of it in 100% of the applications tested. The classic example: a sales rep changes the customer number in the URL and opens a record they should never see. We cover these flaws in detail in Code flaws that leak data.

• The server checks permissions on every request. Hiding a button in the interface protects nothing.
• Roles that match real jobs. Sales sees its own clients, accounting sees invoices, support sees only what it needs to close a ticket.
• Least privilege. New users start with the minimum and get more as needed.
• Bulk export as a separate right. Only a few people should be able to download the whole customer database to a spreadsheet, and every export gets logged.
• Personal accounts, never shared ones. A shared admin login makes it impossible to tell who did what.
• Access ends the day someone leaves. Ideally tied to your HR system or central company login (single sign-on), so it cannot be forgotten.

The other half is signing in. Two-factor authentication is the most common form of multi-factor authentication (MFA). In June 2025 the UK Information Commissioner’s Office fined 23andMe 2.31 million GBP after an attacker used passwords stolen in unrelated breaches to access data on 155,592 UK residents. The ICO found the company had failed to put in place measures such as mandatory multi-factor authentication. For an internal system holding customer data, two-factor authentication should be standard, at least for administrators and for any role that can export data. Our guide on how to secure your phone and accounts shows how to switch it on for everyday accounts.

05Audit logs: who looked at what, and what they changed

When something goes wrong, the first question is who accessed the data. Without an access log, nobody can answer it. Among the security measures in Article 32 of the GDPR is the ability to ensure the ongoing confidentiality and integrity of processing systems. Without a log you cannot show that no one unauthorized saw the data.

• who signed in, when and from where, including failed attempts,
• who opened, changed, deleted or exported which record,
• changes to roles and permissions, and who made them,
• access by administrators and by the vendor, especially outside normal working hours.

Passwords, access tokens, full ID numbers and card numbers do not belong in logs. The log itself must be protected from tampering and have a defined retention period. Keeping it forever makes no sense, but it must not disappear before anyone notices a breach. IBM reports that identifying and containing a breach took 247 days on average.

06Encryption: in transit, in the database and in backups

IBM found that 53% of breached organizations had not encrypted sensitive data both at rest and in transit. Organizations that used encryption had breach costs 213,478 USD below the average.

• In transit: HTTPS everywhere, including between your own services and on API calls. We cover server and certificate setup in Server, HTTPS and cloud security.
• At rest: encrypted disks and databases. In the cloud this is usually a setting, but check that it is actually on.
• Sensitive fields: encrypt ID numbers or health data again inside the application, with the key stored outside the database.
• Passwords: never encrypted, always hashed with a slow algorithm (Argon2, bcrypt), so they cannot be recovered from a leaked database.
• Backups: encrypted, with a different key and different access rights from the live system.

Encryption also has a legal upside. If the leaked data is unintelligible to anyone not authorized to access it, for example because it was encrypted and the key was not compromised, Article 34(3)(a) of the GDPR says the controller does not have to notify the affected people. It does not automatically remove the duty to notify the regulator.

07Live data does not belong in development or on a test server

The quickest way to test a new feature is to pull a copy of the production database. It is also one of the most common ways data escapes a controlled environment. Test servers tend to be less protected, more people can reach them, and copies end up on developers’ laptops.

NIST SP 800-53 (controls SA-3(2) and PM-25) warns that using live data in development and testing carries significant risk, and recommends test or dummy data instead. The GDPR does not explicitly ban testing on live data, but its principles of minimization and protection by design point the same way. A common misconception is that pseudonymized data is no longer personal data. It still is. The EDPB stresses this in its guidelines on pseudonymization, adopted for public consultation in January 2025. If a record can be linked back to a person using a key or other information, the GDPR still applies.

• Use generated data for development that looks realistic but belongs to no real person.
• If you need real volume or structure, anonymize the copy irreversibly while it is still on the production server, before it leaves.
• Keep the test server behind a login and never leave it publicly reachable.
• Developers should not have standing access to the live database. Grant exceptions only for as long as needed, and log them.

/* Test copy: overwrite personal data before it leaves production */
UPDATE customers SET
  name = 'Customer ' || id,
  email = 'customer' || id || '@example.com',
  phone = NULL,
  national_id = NULL,
  note = NULL;

Microsoft’s case shows how easily data escapes outside the live system, even at the largest companies. In 2020 its AI research team published a link to training data on GitHub. The sharing token, however, opened an entire storage account instead of one folder, with full control permissions and an expiry date later pushed out to 2051. According to Wiz, which found the problem in 2023, 38 TB of data was exposed, including backups of two employees’ workstations with passwords, keys and over 30,000 internal Teams messages. Microsoft confirmed that no customer data was exposed.

08Secret keys and source code at your vendor

In October 2022 Toyota announced (the press release is in Japanese only) that 296,019 email addresses and customer numbers of T-Connect users may have leaked. The cause: the contractor developing the T-Connect website had, against the rules, uploaded part of the source code to a public GitHub account in December 2017. The code contained an access key to a data server, and nobody noticed for almost five years.

It is far from rare. According to GitGuardian’s State of Secrets Sprawl 2026, 28.65 million new secrets were added to public GitHub commits in 2025 alone. Of the valid secrets found in 2022, more than 64% still worked in January 2026. We cover how to protect keys and defend against dependency attacks in npm supply chain attacks and API keys.

• The source code repository should live in your company’s account, with the vendor given its own access.
• Passwords and keys belong in a secrets manager or environment variables, never in code.
• Automatic secret scanning should be switched on for the repository.
• Rotate all keys when a vendor relationship ends or a developer leaves.

09AI tools: customer data does not belong in a chatbot

AI has brought a new risk. In IBM’s 2026 report, 43% of security incidents involved shadow AI, meaning tools employees use without company approval, more than double the previous year. All it takes is someone pasting a customer export into a public chatbot and asking for a summary.

On top of that, 92% of organizations that had an AI-related breach lacked proper AI access controls. That applies to AI features inside your own system too. An assistant that answers questions over CRM data must respect the same permissions as the signed-in user, or anyone can ask it anything.

• Decide which AI tools are allowed in the company and with what data.
• Send customer data only to services you have a data processing agreement with and that do not use it for training.
• Tie AI features in the system to the user’s own permissions, and log their queries.

For the obligations under the EU’s artificial intelligence regulation, see our summary AI Act: what businesses must do.

10Backups you can actually restore from

Article 32 of the GDPR expects you to be able to restore access to personal data in a timely manner after an incident. According to Eurostat, 79.2% of EU companies back up data to a separate location. Whether anything can be restored from those backups is another question.

• The 3-2-1 rule, which the UK’s NCSC calls the most common method for resilient backups: at least three copies, on two different devices and one offsite.
• At least one copy offline or immutable, so ransomware cannot encrypt or delete it. The US agency CISA recommends offline, encrypted backups that are tested regularly.
• Backups with separate access rights from the live system. Whoever takes over the server must not get the backups with it.
• Test restores for real on a regular schedule, not just check that the backup job ran.
• Agree in advance how long the system can be down and how much data you can afford to lose. That sets how often you back up.

11Where the data lives: hosting, cloud and transfers outside the EU

Any service that stores or processes personal data on your behalf is usually a processor under the GDPR: hosting, cloud, email delivery, error tracking in the app and AI services. A processor may not bring in another processor without your authorization (Article 28(2)). Ask your vendor for a list of every service the data will pass through, along with the country where it is stored.

For US services, the EU-US Data Privacy Framework matters. The European Commission adopted it on 10 July 2023, and it covers only US companies that have self-certified under it. The EU General Court dismissed a challenge to it in September 2025, but the claimant has appealed to the Court of Justice. If you serve EU customers, keeping their data in the EU is simpler.

The cloud does not mean the provider handles security for you. In 2024 Mandiant and Snowflake notified around 165 customers of the Snowflake data platform that their data may have been stolen. Mandiant’s investigation found no evidence that Snowflake’s own environment had been breached. The attackers used stolen credentials for accounts without multi-factor authentication, in many cases unchanged for as long as four years.

Plan your exit, too. The EU Data Act has applied since 12 September 2025 and requires cloud providers to make switching to another provider easier. From 12 January 2027 they may no longer charge any switching or data egress fees, according to the European Commission.

12The vendor contract: what it must include

Vendors are now one of the main routes to your data. Third parties were involved in almost half of all breaches in Verizon’s 2026 report. If your developer touches personal data while building, running or supporting the system, they are a processor, and Article 28 of the GDPR requires a written contract. Among other things, it should cover:

• processing only on your documented instructions, and confidentiality for everyone at the vendor with access to the data,
• specific security measures (encryption, two-factor authentication, logging, backups), not just a reference to Article 32,
• subcontractors only with your approval and under the same obligations,
• breach notification without undue delay, ideally with a deadline in hours so you can meet your own 72-hour deadline,
• help with requests from people who want to see or delete their data,
• help with your own security, breach notification and impact assessment obligations (Articles 32 to 36),
• return or deletion of the data, including copies, when the contract ends, at your choice,
• a right to audits and inspections,
• beyond the GDPR: source code and repository in your account, a security test before launch, dependency updates and individual accounts for every person at the vendor.

If your company falls under the NIS2 directive as an essential or important entity, supply chain security is part of the risk management measures you must have in place, and your national law may require security clauses in vendor contracts. We explain what this means for management in App security for executives: NIS2 and the CRA. If a vendor goes silent and still holds your code and data, our guide on taking over a website from an unresponsive developer walks through what to do.

13When data leaks anyway

The time to write an incident response plan is not the day of the breach. Deadlines are short and they start when you become aware of the problem.

If you cannot notify your data protection authority within 72 hours, you must explain the delay. Every breach has to be documented internally, including the ones you are not required to report. Regulators will want to know what measures you had in place before the incident.

Your plan should say who decides what happens next, how to reach the vendor outside office hours and how quickly you can find out who accessed which records. This is where the audit log earns its keep. Without one, you often cannot show what stayed safe, and you have to assume the worst.

14Questions to ask your developer

Before you sign a contract for custom software, ask your vendor these eight questions. A good one will give you specific answers without having to think for long.

If you are still deciding whether you need custom software at all, read Have you outgrown Excel?. Typical development prices are in our price list.

15Frequently asked questions

16Sources

• IBM: Cost of a Data Breach Report 2026
• Verizon: 2026 DBIR Executive Summary
• CMS GDPR Enforcement Tracker: statistics
• OWASP Top 10:2025, A01 Broken Access Control
• GDPR on EUR-Lex
• EDPB: Guidelines 4/2019 on Article 25
• EDPB: Guidelines 01/2025 on Pseudonymisation
• NIST SP 800-53 Rev. 5
• Eurostat: ICT security in enterprises
• ICO: 23andMe fined for failing to protect UK users’ genetic data
• Wiz: 38 TB of data exposed by Microsoft AI researchers
• Microsoft MSRC: exposure via an overly permissive SAS token
• Toyota: T-Connect press release (Japanese)
• Mandiant: UNC5537 and Snowflake
• GitGuardian: State of Secrets Sprawl 2026
• NCSC: Offline backups in an online world
• CISA: #StopRansomware Guide
• European Commission: EU-US Data Privacy Framework
• European Commission: Data Act explained
• NIS2 Directive on EUR-Lex