← Back to the blog
26 October 2026

Okay, But Actually… A Breach Does Not Mean Calling Every Government Agency

Okay, But Actually… A Breach Does Not Mean Calling Every Government Agency

Someone commented on one of Pedro's posts that a custom app would need audit logs so the developer could notify “the different government agencies around the world” after a breach.

That is a confident amount of worldwide administration for an app they have never seen.

Yes, a business may have to report a breach. It may also have to tell the people affected. But there is no button marked REPORT TO PLANET EARTH, and an audit log cannot decide which laws apply.

Find out what happened first

Imagine the business spots eighty file downloads from an account that should have been closed when an employee left. Locking the account comes first. The logs can then show whether the downloads completed and which client folders were opened.

If those folders held names, home addresses and invoices, the business may be dealing with a personal data breach. If the app blocked the sign-in and merely recorded eighty failed attempts, no customer records were exposed. Before anyone calls a regulator, it helps to know which of those things happened.

Somehow, “check whether the breach actually happened” did not make it into the worldwide notification plan.

Portugal has a test, not a panic button

For a Portuguese business covered by the GDPR, a breach involving personal information must be assessed for the risk it creates for people. The Portuguese Data Protection Authority, the CNPD says the business must notify it within 72 hours unless the breach is unlikely to put people's rights and freedoms at risk. That page is in Portuguese.

The business must still keep a record of the breach when it decides that notification is not required. If the risk to the people affected is high, they may need to be told too. The European Data Protection Board explains the same distinction: record every personal data breach, report the ones that create risk, and contact the people affected when the risk is high.

The 72 hours do not give the business three days to ignore the problem and then have a dramatic meeting. It should start investigating immediately. It can make an initial report and add details as the investigation continues.

Before the impressive international phone tour begins, we still need the name of the business, the people involved, the information exposed and the harm it could cause.

Other countries have their own rules

If UK rules apply to the business and the people affected, the Information Commissioner's Office also requires certain personal data breaches to be reported within 72 hours. It does not require every breach to be reported. The test is whether the incident is likely to risk people's rights and freedoms.

Australia uses different language. Its Notifiable Data Breaches scheme applies to organisations covered by that law and requires notification when a breach is likely to cause serious harm and the risk has not been removed through remedial action.

The rules that apply depend on more than a pin on a map. The business may be established in one country, offer services in another and use suppliers elsewhere. Some industries have extra reporting duties. Contracts may also require a business to tell a client about an incident even when a government report is not required.

A real incident involving several countries may need advice from somebody who understands the relevant privacy laws. Fine. That still does not justify promising in advance that every regulator everywhere gets a notification.

Who tells whom?

In my usual projects, the client owns the app's accounts and decides why its customer information is collected. If I have access to the live app for maintenance and discover a possible breach, I tell the client immediately and help establish what happened. I do not announce it to a regulator before the client even knows there is a problem.

Buying established software does not make this disappear. If the platform suffers a breach, it may have to tell the business. The business then has its own decisions to make about regulators and customers. If one of its employees exports a customer list and sends it to the wrong person, the software vendor does not become responsible for handling the whole incident because its logo was on the screen.

Under the GDPR, a company processing personal information for a client must tell that client about a breach without undue delay. The client, as the controller, handles the assessment and any required report to the authority. The developer or platform should provide the information needed for that assessment rather than leaving the client to guess.

The app can help. It can record access, preserve useful details and make it possible to disable an account. Monitoring can bring unusual activity to someone's attention. None of that turns the software into the client's lawyer.

Existing software needs a plan too

Some of this may already appear in the software provider's terms. The provider may promise to notify the account holder if the provider itself suffers a breach. Fine. Which email address belongs to the account holder? Does anyone still read it? Who at the business decides what to do with the message?

The provider's terms will not cover every incident inside the business. A member of staff might share an administrator login, send an export to the wrong person or leave a connection running after the company stops using it. If a consultant built the business's workflows inside the platform, the business also needs to know whether that consultant will help investigate a problem.

Before launching custom software, or carrying on with software the business already uses, decide who receives security alerts, who can remove access and who helps work out what happened. Keep a list of the services that hold customer information and a contact for legal or privacy advice if an incident becomes serious.

Apparently this planning becomes an urgent requirement when a developer writes custom code, but not when a consultant builds fifteen workflows inside a subscription. The customer information will be delighted to learn that one arrangement came with a familiar logo.

Ask me whether an app records the information needed to investigate a breach. Ask how quickly I would tell the client and what help I provide afterwards. Ask the same questions about software the business already pays for and the person who configured it.

None of those answers requires an automated hotline to every government department on Earth. That idea still sounds less like an incident plan and more like somebody confused an audit log with a very nervous switchboard.

Want a site like this?

Take a look at the packages, or just say hello.

See the packages →