When a client sends an unexpected attachment, leave it unopened and verify the request through a contact route your organization already trusts. Record the concern and use the approved security escalation process. You can keep helping the client without downloading the file, following its links or asking a colleague to try it instead.
Service teams routinely receive briefs, invoices and complaint evidence. A plausible filename can make an unusual request feel ordinary. Independently confirm the request and use the organization's approved controls.
A familiar name is only part of the story
A design studio may expect a revised brief. Check whether the file was expected, its purpose matches the case and the message asks for an unusual action. Pressure to sign in, install software or change security settings deserves caution.
Microsoft's current phishing guidance advises caution with unexpected attachments, even from recognized sources, and verification through known channels. Poor spelling can be a warning, but polished writing is not a safety certificate.
The separate account security checklist covers account and team controls. This guide concerns the agent receiving a questionable file during an otherwise legitimate service conversation.
Verify outside the suspicious request
Use a previously verified customer record, established telephone number or approved client portal to confirm the request. Do not use a new number, link or sign-in page supplied by the questionable message. Ask whether the client sent a file, its purpose and the approved route for sharing it.
- ContextVerify the request independently.
- SafetyUse approved technical review.
- ServiceKeep the customer owner visible.
Suppose a client unexpectedly sends an updated project brief and asks the studio to use a new document login. The agent can check the existing case record and contact the established client representative independently. A reply inside the same uncertain thread does not resolve the identity question by itself.
| Observation | Front-line action | What remains unresolved |
|---|---|---|
| File was not expected | Hold opening and confirm the purpose | Whether it belongs to the real client |
| New login or installation requested | Stop and use the security route | Whether the destination is trustworthy |
| Client confirms sending | Follow the approved file-review process | Technical safety of the actual file |
Sender confirmation establishes context. The file still needs the organization's normal security checks. Keep those two decisions separate.
Keep the service conversation moving
Acknowledge the customer's request without claiming that the attachment has been reviewed or accepted. Ask for a short description of the business need if that can be shared safely in ordinary text. Do not request passwords, full payment details or unnecessary personal records to prove the request is real.
In a shared inbox, keep one visible owner for the customer response. A security referral should not make the original service question disappear. Record what is paused, who is reviewing it and what the customer can expect next, without promising a resolution time the reviewer has not agreed.
Explain the approved submission route calmly. Avoid accusations before investigation; a legitimate customer may be unaware of account or file misuse.
Report the case without spreading the file
Follow the security team's reporting procedure. Provide the conversation reference, sender details already visible, time received and reason for concern. Share the suspicious object only through the approved reporting mechanism. Do not forward it to a colleague's personal account or upload confidential client material to a public scanning website.
Microsoft's phishing techniques guidance describes attachment lures, nested documents and QR codes that lead to pages that steal sign-in details. A PDF label, preview or familiar brand does not establish that every action inside it is safe. The agent should not investigate by opening nested files or scanning the code.
If someone has already interacted, tell the security team what happened promptly and follow its incident instructions. Avoid experimenting with the file or improvising cleanup. This article does not replace your incident response procedure.
Resume through an approved route
After review, record the authorized outcome and continue through the agreed channel. If a replacement is needed, obtain it through the established client route and apply the normal checks. Do not infer clearance from silence or from the customer repeating that the file is urgent.
The document workflow guide explains how an accepted document joins a case and version history. The retention guide addresses proportionate storage. Neither requires spreading suspicious material into extra copies.
For a professional services team, start by agreeing the trusted verification route and reporting owner with your security lead. Practice with a harmless fictional scenario. Do not use a real suspicious file as a training exercise.
Frequently asked questions
Does a known customer make an attachment safe?
No. Confirm an unexpected request independently and follow approved file checks. Familiar identity and technical file safety answer different questions.
Can I open it just to see what it contains?
Avoid testing it yourself. Record the reference and use the approved review route. A preview or nested link can still create exposure.
Should I ask another agent to try it?
No. Keep the file within the approved security process and preserve service ownership. Moving the same uncertainty to another person does not resolve it.
Want help applying this guide?Ask the DripTell team
From reading to action
Want help applying this to your business?
Share your details. We will read the article you are on and start with a useful answer for your team.
DripTell Editorial
Practical guidance reviewed by the DripTell product and customer workflow team.
See how DripTell checks product claims, uses primary sources and handles corrections.
Editorial and source policy
