A revised document. An invitation to a project portal. An urgent request to change a supplier's details. Construction teams receive messages that are meant to prompt action.
The difficult moment is often when a familiar-looking message asks somebody to do something outside the usual process. The project name may be correct. The sender may appear convincing. That still leaves questions about the instruction and who is authorised to give it.
A useful process helps someone check the request without expecting them to investigate a cyber incident themselves.
Check three different things
The sender and channel: is the message genuinely from the person or organisation it appears to represent? Appearance alone is insufficient. A real account can also be compromised.
The authority: even a genuine contact may not be authorised to approve new access, release confidential tender material or change payment instructions.
The action: does the instruction fit the agreed process, and which colleague should approve it?
Those are related questions, not interchangeable ones. An email address matching an expected name does not settle the authority to change a process.
Agree the route before the unusual request arrives
| Request | Proportionate next check |
|---|---|
| Unexpected portal sign-in | Use the established route to the service; ask IT about an unusual sign-in or access request |
| Wider access to project files | Confirm the need and approval with the project or information owner |
| Customer or tender material requested through a new channel | Check permitted sharing and recipient authority before releasing it |
| New supplier bank details | Refer to Finance's established verification and approval process |
| Urgent instruction to bypass a check | Confirm with the appropriate authorised person using an independently established contact route |
Do not use a new phone number supplied in the suspicious message as the only verification route. The checking process should not depend on information the same message is asking you to trust.
An illustrative construction example
A message names the right project and asks a colleague to sign in to see an updated document. They were expecting a drawing revision, so the context feels plausible.
The useful instruction is to reach the known project platform through the established route, or check with the recognised project contact. If the request is unusual, IT should have an accessible reporting route. The person receiving the message should know that asking for help is the expected action.
This is an illustrative scenario. It is not an incident involving an Assured Digital customer, and clicking a link does not automatically establish that an account or device has been compromised.
Give people a workable response if they have already acted
Ask them to report promptly through the agreed route, with what they did and when. Preserve the message where instructed and let the responsible team assess the situation. Do not ask them to run an investigation or conceal the mistake.
If credentials, payment details or sensitive information may be involved, escalate to the appropriate IT, Finance or incident lead. Those people should follow the organisation's response arrangements and determine the required containment, communication and reporting.
AI makes appearance a weaker reassurance
Good grammar and a convincing tone were never enough to verify a request. NCSC assesses that AI will make elements of cyber intrusion more effective and efficient. That strengthens the case for dependable verification and technical protection; it does not establish that any particular message was generated by AI. NCSC AI threat assessment.
Support the process with technical controls
NCSC recommends layered phishing defences rather than relying on users alone. The organisation should combine appropriate technical measures, reporting and response with staff guidance. NCSC phishing guidance.
For IT, the next discussion may concern email and identity controls, device protection or incident handling. The available capabilities depend on the systems, licences, configuration and support actually in place. A product name on an invoice is not a complete description of that arrangement.
For HSEQ, Commercial and Operations, the useful contribution is a clear workflow: who can approve the change, how to check it and who handles a concern.
Keep a short record
Record the type of request, established verification route, authorised approver, action taken and any follow-up. Keep sensitive evidence in the agreed secure location; a reference is often enough for the working record.
Next step: Review the wider controls with Assured Digital's Cyber Health Check. It is a self-review to help choose what deserves further attention, not a test of whether an email is safe or proof that every safeguard works.
