What the Revolut data breach teaches organisations about trust, verification and secure workflow design

A convincing request from a legitimate domain can still be fraudulent. The lesson for business leaders is clear: protecting sensitive information requires more than secure infrastructure. It requires well designed processes that verify the request, the requester and the authority behind every high risk disclosure.

Most organisations have invested heavily in protecting networks, applications and accounts. They use multi-factor authentication, monitor suspicious logins, patch systems and train people to identify phishing emails. These controls remain essential, but a recent incident involving Revolut highlights a different and increasingly important weakness: an attacker may not need to break into the organisation at all if they can persuade it to release the information through an apparently legitimate process.

In September 2026, TechCrunch reported that Revolut had disclosed sensitive customer information after receiving fraudulent information requests sent from a legitimate government agency email domain. According to the report, the exposed information may have included names, dates of birth, postal and email addresses, phone numbers, identity documents, verification selfies, account statements and transaction histories. Revolut said that a limited number of customers were affected, that its systems and customer funds were not compromised, and that it had notified affected customers and relevant authorities.

The publicly available reporting does not establish every detail of the incident, and it would be unwise to speculate about the specific controls or decisions involved. Even so, the scenario presents a valuable lesson for every organisation that handles personal, financial or commercially sensitive information. A legitimate email account, domain or communication channel can establish where a message came from. It cannot, by itself, prove that the person sending it is authorised to make the request, that the request is lawful, or that the requested disclosure is appropriate.

That distinction matters because many of the most damaging security incidents do not begin with an obvious technical failure. They begin with a credible story, a familiar process and a request that seems reasonable enough to action.

The new trust problem

Traditional phishing awareness has taught people to look for misspelled domains, unusual links, poor grammar and urgent demands. Those signals are still useful, but they are less dependable when an attacker has access to a genuine mailbox or a legitimate organisation’s domain. In that situation, the message may pass normal email authentication checks. The sender’s address may look correct. The language may resemble earlier correspondence. The request may even refer to real people, cases or procedures.

The message can therefore be technically authentic while the request itself remains fraudulent. This is the central issue. Sender authentication answers one question: did this message originate from the account or system it claims to come from? Authorisation answers another: is this person permitted to request this information for this purpose, and should our organisation release it in these circumstances?

Strong security depends on answering both questions. When an organisation treats possession of a trusted mailbox as proof of authority, a compromised external account can inherit too much trust. The attacker benefits from the reputation and access of the legitimate organisation without needing to compromise the victim’s own network.

This is one reason modern security thinking moves away from permanent or implicit trust. Every sensitive action should be evaluated in context. Who is making the request? What authority do they have? Is the requested information proportionate? Does the request match expected patterns? Has it been verified using an independent channel? Has the right person approved the disclosure?

A data breach can be a process failure

Cyber security is often discussed as though it sits primarily with the technology team. That view is too narrow. A disclosure may occur without malware, a vulnerability or unauthorised access to the organisation’s systems. If an employee follows an apparently valid request and exports data through an approved interface, every technical control may behave exactly as designed while the outcome is still wrong.

This is not an argument against technical controls. It is an argument for designing technical controls and operational processes as one system. Security depends on the complete path from receiving a request to deciding what may be disclosed, obtaining approval, extracting the minimum necessary information, transferring it securely and retaining an audit record.

A weak point anywhere along that path can undermine the whole process. For example, an organisation may tightly restrict database access but allow authorised staff to export complete customer records without a second approval. It may use encrypted file transfer but rely on email alone to verify the recipient. It may log the final export but not record the evidence used to validate the underlying request.

This is why secure software development should not be limited to preventing technical exploits. Good digital systems also guide people towards safe decisions. They make high risk actions deliberate, visible and reviewable. They reduce the amount of judgement that an individual must exercise under time pressure, while still giving trained staff a clear route for unusual or urgent cases.

Why this matters for Australian organisations

The Australian privacy framework reinforces this broader view. Australian Privacy Principle 11 requires covered entities to take reasonable steps to protect the personal information they hold from misuse, interference, loss and unauthorised access, modification or disclosure. Current guidance from the Office of the Australian Information Commissioner states that these reasonable steps include both technical and organisational measures.

The OAIC also recommends a layered approach that avoids a single point of failure. This is directly relevant to fraudulent information requests. If email origin is the only meaningful check, the process has a single point of failure. Once the external account is compromised or misused, the attacker can move through the process using the trust attached to that account.

The sensitivity and volume of information matter too. Identity documents, financial records and transaction histories can create serious and lasting risks for affected individuals. Unlike a password, a passport number, date of birth or historical transaction record cannot simply be replaced in the same way. Organisations should therefore apply stronger controls as the sensitivity, scope and potential consequences of a disclosure increase.

Data retention is part of the equation. APP 11 also requires organisations to destroy or de-identify personal information that is no longer needed, subject to applicable legal requirements. Reducing unnecessary holdings does not prevent every incident, but it reduces the information available to be exposed and can limit the consequences when something goes wrong.

For organisations operating across several jurisdictions, the position can be more complex. Privacy obligations, lawful access procedures, regulatory reporting requirements and government request mechanisms vary. The practical principle, however, is consistent: a request for sensitive information should be validated against a defined authority and an established process, not accepted because the message appears credible.

Seven controls that reduce the risk

1 Verify requests through an independent channel

High risk requests should be confirmed using contact details and channels already known to the organisation. Staff should not rely on the phone number, link or verification instructions contained in the incoming message. For government or law enforcement requests, this may mean using an official portal, contacting a verified agency switchboard, checking a recognised case management system or confirming the request with an established liaison.

Australian Cyber Security Centre guidance on business email compromise recommends verifying unusual requests by calling the sender on a known and verified phone number. The same principle applies beyond payment fraud. The more sensitive the information, the more important it is to separate the request channel from the verification channel.

2 Verify authority as well as identity

Knowing who sent a request is not enough. The organisation must also know whether that person or agency has the authority to request the information, whether the request meets the relevant legal or contractual requirements and whether the scope is valid. A genuine employee of a government agency may still have a compromised account, may be acting outside their authority or may have requested more information than the process permits.

A mature workflow records the claimed authority, the evidence supporting it, the internal basis for disclosure and the person responsible for approval. Where legal interpretation is required, the system should route the request to the appropriate privacy or legal specialist rather than expecting operational staff to make the decision alone.

3 Use approval controls that reflect the risk

Not every information request requires the same treatment. A request for a generic service record presents a different risk from a request for passports, verification images and complete transaction histories. Approval requirements should increase with the sensitivity, volume and breadth of the requested data.

For higher risk disclosures, two person approval can provide a valuable safeguard. One person validates and prepares the response. Another reviews the authority, scope and proposed data before release. The purpose is not bureaucracy for its own sake. It is to make consequential decisions visible and less dependent on a single person’s judgement.

4 Release only what is necessary

A valid request does not automatically justify disclosing every available record. Systems should allow teams to select and export the minimum information necessary for the authorised purpose. Broad customer profiles and default full record exports create unnecessary risk.

Purpose based export templates can help. If a particular lawful request normally requires three defined fields, the workflow should present those fields by default and require a separate justification for anything additional. Sensitive attachments such as identity documents should be individually selected, clearly labelled and subject to enhanced approval.

5 Build anomaly detection into the process

Fraudulent requests may differ from normal activity even when they come from a trusted account. Useful signals can include an unusual volume of requests, a sudden change in the categories of information sought, requests involving high profile or high net worth customers, new recipients, activity outside normal hours or repeated requests that bypass the usual portal.

These signals do not need to block every request automatically. They can increase the required approval level, trigger an independent callback or alert the privacy and security teams. The objective is to convert unusual context into a deliberate review rather than leaving it invisible.

6 Maintain a complete audit trail

An audit log should explain the full decision, not merely show that a file was downloaded. It should record the original request, requester details, verification steps, legal or policy basis, approvers, data selected, transfer method, recipient and time of release. This improves accountability, supports incident investigation and helps organisations identify patterns that would otherwise remain spread across inboxes and systems.

Audit records must also be protected from inappropriate alteration and access. Logging creates value only when the records are reliable, searchable and retained for an appropriate period.

7 Test the workflow, not just the infrastructure

Penetration testing, vulnerability scanning and access reviews remain important, but they may not reveal whether a believable request can produce an unauthorised disclosure. Organisations should test high risk workflows through scenario exercises that involve security, privacy, legal, customer operations and executive leadership.

A useful exercise might simulate a valid looking government request from a trusted domain, an urgent executive request for customer information or a supplier account that has been compromised. The test should examine whether staff recognise the risk, whether the system enforces independent verification, whether escalation paths work and whether the organisation can reconstruct the decision afterwards.

Questions every executive should ask

Executives do not need to design each control themselves, but they should be able to obtain clear answers to the following questions:

• Which workflows can result in personal, financial or commercially sensitive information leaving the organisation?
• Which external parties are treated as trusted requesters, and how is that trust verified over time?
• Can a single employee approve and complete a high risk disclosure?
• Do we verify unusual requests using a channel that is independent of the original message?
• Can our systems limit exports to the minimum information required, or do staff rely on broad manual downloads?
• What events trigger enhanced review, and who receives those alerts?
• Could we reconstruct exactly why a disclosure was approved six months after it occurred?
• When did we last test this process using a realistic impersonation scenario?
• Are we retaining identity documents or other sensitive information longer than necessary?

If the answers are unclear, the organisation may have strong technology but an incomplete control environment. That gap is where convincing requests, compromised third parties and operational pressure can become data breaches.

Security must be designed around decisions

The most important lesson from the reported Revolut incident is not that organisations should distrust government agencies or abandon email. It is that trust must be specific, limited and supported by evidence. A familiar domain is one signal. It should never be the entire control.

Organisations need workflows that verify identity, confirm authority, challenge unusual context, minimise disclosure and preserve a reliable record of the decision. Those workflows should be built into the systems people use every day, not left as a policy document that staff must remember during an urgent request.

This is where secure software design and sound governance meet. Technology can make the safer path the easier path. It can require the right approvals, prevent excessive exports, highlight anomalies and give decision makers the context they need. Clear policies, training and accountability then ensure that the controls are understood and used properly.

Cyber security is no longer only about keeping attackers out. It is also about ensuring that trusted users, working through legitimate systems, cannot be manipulated into producing an illegitimate outcome. Organisations that design for that reality will be better placed to protect customers, meet their privacy obligations and respond confidently when a convincing request arrives.

How Newpath can help

Newpath works with organisations to design, build and improve secure digital platforms, websites and mobile applications. That includes examining the workflows around sensitive data, not just the code that stores it. If your organisation needs to strengthen an information release process, modernise a high risk operational workflow or build security and privacy into a new digital product, our team can help turn the control requirements into a practical, usable solution.

Talk to Newpath about secure digital platform and workflow design.