When organisations think about a data breach, attention often turns to attackers exploiting vulnerabilities, stealing credentials or gaining access to a network. The recent Revolut incident highlights another route: persuading an organisation to release information through an apparently legitimate request.
According to reports an unauthorised third party obtained customer information by submitting fraudulent requests from an email address associated with a genuine government agency domain. Revolut said its systems and customer funds were unaffected. Customer notifications described in the report indicated that identity documents, verification selfies and financial records were among the information exposed.
The incident illustrates why data protection and cyber security cannot be treated as completely separate things. The technology might be working exactly as intended. The vulnerability can still be the decision someone makes when a request looks legitimate.
Apparent authority should never remove the need for independent verification. Requests for sensitive information deserve scrutiny even when they appear to come from a government agency, regulator or familiar third party, as highlighted in our CTO Richard Ford’s comments to Sync NI.
A credible email address is one piece of information. It does not establish whether the person using it is entitled to receive particular records, whether the purpose is genuine or whether the amount of information requested is appropriate.
The public reporting does not provide enough detail to assess every step of Revolut’s internal process. However, organisations can use this incident to examine their own arrangements. If an official-looking request arrived tomorrow, what would happen before someone released customer information? Would the checks be clear and consistent, or would they depend on an individual deciding that something felt wrong?
That distinction matters because convincing requests are designed to avoid raising suspicion.
An employee can authenticate securely, open a file they are authorised to access and share it using an approved platform, yet still disclose information to the wrong person.
Access controls establish what an employee can do within a system. They do not necessarily establish whether a particular business action is justified. That requires context: the purpose of the request, the recipient’s authority and the information needed to fulfil it.
This is where security, data protection and operational teams need a shared process. Together, they should define who can approve disclosures, how sensitive records can be shared and what evidence must be retained.
A policy that says customer information must be protected needs to translate into practical decisions and system controls. Otherwise, employees are left to interpret the requirement while dealing with an inbox full of competing demands.
Verification procedures should cover requests for sensitive records as well as financial transactions. An apparently credible source should not be enough to authorise a disclosure.
In practice, independent verification means using a contact route established separately from the incoming message. Replying to the same email or calling a number supplied within it does not provide an independent check.
The process should answer several questions:
Organisations should also make the outcome of those checks visible to the person releasing the data. Recording an approval, its scope and the verified recipient helps prevent an initially valid request from expanding into an inappropriate disclosure.
Attackers can use authority, urgency and relevant context to make requests convincing. Awareness training needs to help employees recognise those pressures and question them, particularly when a message appears to fit an existing business relationship.
A useful exercise is to walk through a realistic disclosure request with the teams who would handle it. Where would it arrive? Who would assess it? What happens if the usual approver is unavailable? Can an employee pause the request without being challenged for delaying a response?
Those discussions can expose weaknesses that a written policy misses. They also give staff a chance to practise decisions before facing them under pressure.
Responsibility cannot rest entirely with the person reading the message. Managers need to support verification, while workflows should make checks easy to complete and difficult to bypass. Additional approval for sensitive disclosures, restrictions on bulk exports and monitoring of unusual sharing can provide further protection.
Stolen personal information can retain its value long after the original disclosure, supporting fraud and increasingly convincing phishing attempts. Details obtained in one incident may give a later approach enough credibility to persuade someone to share further information.
That makes the scope of any release important. Even a verified request should not automatically result in a complete customer record being shared. Organisations should establish precisely what is needed and limit the disclosure accordingly.
Incident planning should also connect security and data protection teams from the outset. Employees need a clear reporting route, while those investigating need to establish what was shared, with whom and whether further disclosures can be prevented.
Integrity360 approaches cyber security across people, processes and technology because protecting information depends on all three working together.
The practical lesson is to examine the point at which someone decides to trust a request. Strong authentication and secure systems remain essential, but they need to be supported by clear approval routes, proportionate verification and employees who feel able to ask questions.
Organisations should be able to explain why information was released, who authorised it and how the recipient was verified. Building those checks into everyday work brings data protection and cyber security together where it matters: before sensitive information leaves the organisation.
Speak to Integrity360 about strengthening your approach to protecting sensitive data and managing social engineering risk.