Alex Rozenplenter/September 21, 2026/inBlog/tags:ITSM

GDPR and Data Security in ITSM

One onboarding ticket can hold a full name, home address, device serial and passport scan. Article 32 of the General Data Protection Regulation requires you to ensure a level of security appropriate to the risk.

What personal data your service desk actually stores

An ITSM platform stores more personal data than its contact fields suggest: ticket bodies, ingested email threads, attachments, asset records linking a user to a device. Free text holds the largest amounts of data.

ITSM environments also hold Article 9 categories: health details in onboarding tickets, biometric data from badge enrolment. A payroll screenshot in a printer fault ticket puts sensitive information into a queue never meant to store sensitive data. Data minimization and privacy by design belong in the intake form (Article 25); Article 35 adds a data protection impact assessment.

Controller or processor: who is responsible for what

The organisation running the service desk is the controller for personal data in its tickets; the vendor is the processor. Your role and responsibilities follow from that split, and Article 28 requires a written contract covering data processing.

Definition

Controller: determines the purposes and means of processing personal data.
Processor: processes personal data on the controller’s behalf, on documented instructions.

Managed service providers hold both roles: processor for client tickets, controller for their own staff records in one ITSM software. Two sets of GDPR obligations run through one system, and data segmentation between queues keeps them apart.

Review the sub-processor list before signing: AI features added since 2024 often send ticket text to an external model provider, creating data transfers outside the EEA. Transferring personal data there needs its own safeguards.

Core controls: access, encryption, logging, retention

Four controls carry most GDPR security work within ITSM: role-based access controls, encryption, an audit trail, and enforced retention, all named or implied by Article 32.

Control	GDPR requirements	ITSM setting
Access	Only what each role needs	Separate IT and HR queues, deny by default
Data encryption	In storage and in transit	TLS, AES-256 at rest, field level for Article 9
Logging	Who read and changed what	Immutable audit trail, reviewed
Retention	Limited to the stated purpose	Deletion rules per category, attachments included

Scope matters more than algorithm choice. Disk and database encryption protects data both at rest and in transit, but not a stolen administrator credential, because the platform decrypts on read. Field level encryption on Article 9 fields limits unauthorized data access from inside the team.

Retention is where ITSM processes fail. Platforms archive instead of delete, attachments survive in object storage after the ticket is gone, and daily data backups extend every period you set. Delete data based on ticket category.

The routine failure mode behind ITSM security incidents is human error: a ticket routed to the wrong queue, a reply to the wrong recipient. Role-based access controls prevent neither, but they reduce the risk of insider threats and unauthorized access.

Handling data subject requests in a ticket queue

A data subject request must be answered within one month under Article 12(3), extendable by two if the requester is told within the first. Scope is the difficulty: one person appears across tickets, attachments, logs and backups.

Log the request as its own ticket type and workflow.
Search ticket text, attachments and logs, not only the contact record.
Redact rather than delete when a ticket holds someone else’s data.
Check legal holds before erasure; retention can override it.
Record what was disclosed, redacted, or refused, and why.

Regulators accept deletion of backup copies on the normal cycle if the data is put beyond use meanwhile.

Breach notification: the 72-hour clock

Article 33 requires controllers to report data breaches to the supervisory authority without undue delay and, where feasible, within 72 hours of becoming aware, unless the breach is unlikely to result in risk.

The European Data Protection Board treats a controller as aware only once it holds reasonable certainty that a security incident compromised personal data.

Processors face no 72-hour deadline; Article 33(2) obliges them only to notify the controller without undue delay. Set a contractual limit, commonly 24 hours, and route the trigger through your incident response plan. Non-compliance can result in fines up to 10 million euros or 2% of global turnover.

Certifications and vendor due diligence

SOC 2 and ISO/IEC 27001 are information security frameworks, not evidence of compliance with GDPR. Each shows a vendor runs security controls under independent review; neither addresses lawful basis, retention or the privacy regulations that apply to you, and neither makes your deployment compliant.

Read the report, not the badge. Type II covers a window and lists the exceptions the auditor found; Type I covers a single date. Ask what was in scope, when the last penetration test ran, and how often security audits happen.

Alloy Software completed SOC 2 Type I in April 2025 and Type II in November 2025. Alloy Navigator combines service management with role-based access, data segmentation between departments and a choice of on-premise or cloud hosting; AlloyScan covers discovery and network inventory.

What to check before you buy

Strong data governance is how teams maintain compliance between audits: a named person per queue, a written retention rule per ticket category, and a dated review. Privacy in ITSM is a configuration outcome, and so is GDPR compliance: the same platform can protect personal data or leak it, depending on who set up the queues.

Then test secure data disposal: delete a ticket with an attachment, confirm the file is gone from object storage, and ask when it leaves the backup cycle. A vendor that cannot show this in a trial will not manage it in production.