Every cloud vendor says they’re secure. That’s not a criticism, exactly – it’s just not information. “Enterprise-grade security” tells you nothing you didn’t already assume, and it’s usually the point where a skeptical IT manager stops reading and starts asking real questions about SOLIDWORKS PDM cloud security instead. Good instinct. Your CAD data, your BOMs, your revision history – the entire design record of what your company builds – deserves better than a marketing adjective.
So let’s ask the better questions. Not “is it secure,” but: encrypted how, backed up on what schedule, monitored by whom, and what happens the day something actually goes wrong. If a vendor can answer all four with specifics instead of adjectives, that’s a real signal. If they can’t, that’s a signal too.
Encrypted how, exactly?
“Encrypted” is doing a lot of work in most vendor pitches, and it shouldn’t be trusted without a follow-up question: encrypted where, and with what?
There are at least three places data needs protecting in a hosted PDM environment: at rest on the disk, in transit over the network, and specifically in the file traffic between your client and the archive server. A setup worth trusting handles all three — disk encryption at the storage layer, SSL/TLS on web and database connections, and a documented encryption standard for file transfers. AES-128 is the current benchmark worth asking about, and whether it’s FIPS 140-2 compliant matters if you’re in a regulated industry or supplying to one.
(Worth knowing: this is often tied to your PDM version specifically – older releases sometimes rely on older algorithms that don’t meet current standards, so “we use AES-128” and “your installation uses AES-128” aren’t automatically the same sentence.)
If a vendor answers “we’re encrypted” and stops there, ask again. The good ones will have a three-part answer ready.
Backed up on what schedule, actually?
Everyone claims backups. Almost nobody volunteers the schedule until you ask for it – and the schedule is where the real risk lives, because it defines how much work you could actually lose.
A single nightly backup sounds fine until you’re the team whose server failed at 4pm, meaning the most recent recoverable version is eighteen hours old. Look for layered backup schedules instead: a full snapshot on a short, frequent cycle (daily, retained for a week is a reasonable baseline), a more persistent backup on a longer cycle for deeper recovery, and – this part gets skipped more often than it should – a separate database-level backup, because a snapshot taken mid-write can capture a database in an inconsistent state. Three overlapping schedules isn’t overengineering. It’s the difference between losing an afternoon and losing a week.
Monitored by whom, and how often?
Encryption and backups are what happens when things are working. Monitoring is what happens when they’re not – and it’s the category most vendors gloss over fastest, because “we watch for problems” is a much easier sentence to say than a specific one.
Ask what’s actually running: antivirus with current definitions, a patching cadence for the operating system (monthly is a reasonable standard), and – this is the one worth pushing on – external vulnerability scanning on a defined schedule, not just “as needed.” Weekly external scans, with an automatic rescan triggered the moment a new threat class emerges, is a meaningfully different posture than an annual audit somebody remembers to schedule. The gap between those two isn’t cosmetic. It’s the gap between catching a vulnerability and reading about it after the fact.
What happens the day something goes wrong?
This is the question vendors answer least willingly, because the honest answer requires admitting that something could go wrong at all. But things do, eventually, for every vendor, and what you’re really evaluating is not whether they’re infallible – nobody is – but whether they’ve built for the failure, not just the happy path.
Ask who you’d actually call, whether that’s a specialized team that knows both the PDM software and the hosting infrastructure or a general help desk that’s never seen your setup before. Ask how fast a restore actually happens, in practice, not in theory. A vendor with a real answer to this will give you one without flinching. A vendor without one will redirect back to “enterprise-grade security.”
What good SOLIDWORKS PDM cloud security actually looks like
None of this means cloud-hosted PDM is inherently safer or riskier than what you’re running today – it means “secure” is a claim that only means something once you’ve asked what’s underneath it. A well-run on-premise server can be more secure than a poorly-run cloud one, and the reverse is just as true. The differentiator was never the location. It’s the specificity.
For what it’s worth, here’s how PLM Group answers those four questions for HostPLM: disk encryption at rest through Azure, SSL/TLS across web and database connections, AES-128 file traffic encryption (FIPS 140-2 compliant on current SOLIDWORKS PDM releases), three overlapping backup schedules including a dedicated database-level backup, Windows Defender with monthly security patching, weekly external vulnerability scans through Intruder.io, and a support team that works exclusively in PDM and HostPLM infrastructure – not a general ticket queue.
That’s not a pitch, it’s just what specific looks like. Ask any vendor you’re evaluating the same four questions and see what you get back.
Curious how HostPLM’s setup compares to what you’re running today? Take a closer look, or get in touch and we’ll walk through the specifics – not the adjectives.
