Is your PDM data actually safe in the cloud? Here’s what “secure” should actually mean

Every cloud vendor says they’re secure. Fair enough – but it’s not information, it’s just what everyone says. “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. What’s actually on the line is your CAD data, your BOMs, your revision history – the entire design record of what your company builds.

Not every team connects to PDM the same way, so HostPLM doesn't force one model on everyone.

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 might sound like overkill, right up until the week you’re genuinely glad you had all three.

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 eventually. One of those catches a problem before it becomes an incident. The other one finds out about it from a headline.

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. Location was never the real variable. How specific the vendor is willing to get, is.

For what it’s worth, here’s the shape of PLM Group’s approach for HostPLM: encryption in transit and at rest, regular server backups across multiple retention schedules, antivirus protection paired with an ongoing patching cadence, active external monitoring for emerging vulnerabilities, and a support team that works exclusively in PDM and HostPLM infrastructure – not a general ticket queue. We keep the specific standards, schedules, and tools off a public page on purpose: that detail changes as our infrastructure does, and a direct technical conversation keeps it accurate rather than dated. Ask, and we’ll walk you through exactly what’s running under your account today.

We’re not sharing that list to sell you on it here – we’re sharing it so you have a real answer to compare against, the next time a vendor tells you they’re secure. 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 you through exactly how it works.

Security you can actually verify, not just take our word for.