Dealership Cybersecurity and DMS Resilience Guide

1. Model the dealership's real attack surface

The DMS rarely stands alone. It exchanges customer, vehicle, pricing, repair, parts and accounting data with CRM, OEM portals, finance providers, websites, call systems, diagnostic tools and spreadsheets. Branch networks include office endpoints, workshop equipment, Wi-Fi, printers, cameras and vendor remote access. Each identity and interface is part of the operating boundary.

Start with an asset and data-flow inventory. Record owner, purpose, users, administrator, internet exposure, authentication, integrations, data sensitivity, vendor and recovery dependency. Include dormant interfaces and robotic accounts. Unknown legacy connections are especially dangerous because they can retain broad permissions after their business purpose ends.

ENISA analysed 4,875 incidents for its Threat Landscape 2025. Within its cybercrime subset, ransomware accounted for 81.1%, while ransomware-linked breaches represented 15.2% of incidents overall. [1] Those denominators are different and must not be conflated. The operational lesson is that dealers need both prevention and recoverability.

2. Make identity the security control plane

Require phishing-resistant multifactor authentication where available, especially for administrators, email, remote access and finance. Centralise sign-on where practical and block shared user accounts. Service accounts need owners, narrow scopes, rotated secrets and no interactive use. API credentials should be stored in a secrets manager, not scripts or tickets.

Implement a joiner, mover and leaver process that reflects dealership turnover and role changes. Disable access promptly at departure, remove old branch permissions on transfer and review privileged access regularly. Separate the ability to create a supplier, approve payment, export customer data and change security settings.

Monitor unusual sign-in location, impossible travel, bulk exports, privilege changes, disabled logs and mass record changes. Alerts need owners and response playbooks. Preserve audit logs outside the reach of the account being monitored and synchronise time across systems so investigators can reconstruct events.

3. Reduce technical exposure and integration risk

Patch internet-facing and exploited vulnerabilities first, using asset criticality and threat evidence. Remove unsupported remote-control software and close unused ports. Segment diagnostic and workshop devices from finance and identity services. Vendor access should be time-bound, approved and monitored.

Secure integrations as production software. Validate schema and authorisation, use idempotency to prevent duplicate financial events, limit data returned and protect webhook endpoints against spoofing and replay. Apply separate credentials per environment and partner. A single all-powerful integration account defeats role design.

4. Design recovery around dealer operations

Define recovery point objective, recovery time objective and maximum tolerable outage for lead intake, workshop scheduling, parts, invoicing, vehicle release and payroll. Dependencies matter: restoring the DMS without identity, DNS, document storage or an OEM link may not restore useful service.

Maintain immutable or isolated backups protected by credentials separate from production administration. Test restoration to a clean environment and verify data consistency, not merely that files exist. Record time taken and manual steps. Retain vendor contacts and licence information in an offline response pack.

Prepare controlled downtime procedures: how to verify customers, capture work, authorise vehicle release, record parts, protect paper forms and reconcile transactions after recovery. Practise with branch leaders. Manual continuity is not a licence to bypass fraud and privacy checks.

5. Treat suppliers as part of the control environment

Request evidence proportionate to risk: hosting and data residency, encryption, identity controls, audit logs, secure development, vulnerability management, independent assurance, penetration testing approach, incident history, subprocessors, continuity, data return and deletion. A certificate is useful but does not answer whether a dealer has configured MFA or oversized permissions.

Contracts should define incident notification, cooperation, evidence preservation, recovery targets, subprocessor changes and exit support. Map fourth parties that can materially disrupt service. Reassess at renewal and after major architecture or ownership changes.

For personal data, GDPR Article 32 requires controllers and processors to use measures appropriate to risk, including as appropriate encryption, resilience, restoration and regular testing. [2] This is risk-based, not a fixed checklist.

6. Understand NIS2 and vehicle rules without overclaiming

NIS2 is Directive (EU) 2022/2555, so Member States transpose it into national law. Scope depends on sector, entity type, size rules, national choices and designation. Manufacturing of motor vehicles appears in Annex II, and certain cloud, managed-service and digital providers are covered categories. An ordinary dealership is not automatically in scope simply because it sells or services vehicles. [3]

Even when a dealer is outside direct scope, OEM or supplier contracts may pass through requirements. Covered entities face governance, risk-management and incident-reporting duties under national implementation. Verify the legal entity and current national legislation rather than relying on an EU-level summary.

UNECE Regulations No. 155 and 156 address vehicle cybersecurity and software-update management in the type-approval framework. [4] They primarily concern manufacturers and approved vehicle types, not certification of every dealership DMS. Dealers can nevertheless support controlled software updates, campaign evidence and incident escalation in the wider automotive chain.

Where Omnetic fits

Omnetic's documented modules connect CRM, vehicle lifecycle, stock, pricing and inspection workflows. Fewer uncontrolled handoffs can improve operational visibility, but consolidation also concentrates dependency and must be protected accordingly. Product documentation references APIs, webhooks, external identifiers and scheduled exports without publishing a complete public security or interface catalogue.

Before selection, ask Omnetic to evidence hosting, residency, encryption, RBAC, MFA or 2FA, audit logs, backup isolation, recovery tests, incident terms, vulnerability management, subprocessors and integration security. Validate configuration and responsibilities in the intended country and package.