By default, the helpdesk now sends notifications only by email, rather than including the full ticket response in the message body.

This change was made for security reasons following a recent NIS2 audit. The audit identified that sending full ticket replies by email as the default created unnecessary risk, particularly where an engineer might include credentials or other sensitive information and rely on manually unticking or ticking an option at the point of reply.

Why this changed

Previously, the helpdesk could send the full contents of a ticket response by email. While convenient, this approach has an important weakness:

• email is not a secure channel for sensitive operational information
• messages may be forwarded, misdirected, stored in multiple mailboxes, or retained outside normal access controls
• sensitive data such as passwords, API Keys, recovery details, configuration information, or internal system information could be exposed if included in an email reply
• the old approach depended on the engineer remembering to change the send behaviour when sensitive content was involved
• there was an opportunity for a bad actor to leverage a phishing campaign simulating HelpDesk messaging to elicit information

The NIS2 audit found this to be an unacceptable and avoidable risk. As a result, the default was changed so that:

• ticket updates are sent as notifications by default
• the recipient is alerted that the ticket has been updated
• the full response is intended to be viewed securely through the ticketing portal
• if an engineer explicitly chooses to send the ticket entry by email, that must now be a deliberate action

This reverses the previous risk model. Instead of relying on staff to stop sensitive information being emailed, the system now assumes that email should not contain the full ticket content unless there is a specific reason to do so.

What users must do

All users should follow these rules:

1. DO NOT EVER paste credentials into an email
2. DO NOT EVER reply to ticket notifications with passwords or sensitive secrets
3. Log in to the ticket portal to review full ticket responses
4. Use approved secure methods for sharing secrets where required
5. Challenge any request for credentials that arrives by email

What engineers and staff must do

When updating tickets:

• use the default notification-only behaviour unless there is a clear reason to send content by email
• treat email as unsuitable for secrets or sensitive technical detail, or any detail which could be useful to a third party
• only choose to send the ticket entry by email when the content is appropriate for email distribution and it is specifically requested