What to Ask a CSMS Vendor About Security and Availability

Charging platform deals rarely fail on features. They stall in security review, usually several weeks after everyone technical has already agreed the product is the right one. The reason is almost always the same: the vendor's security page answered the questions the vendor chose to answer, and the buyer's security team has a different list. This post is that different list - what to ask a CSMS vendor about security and availability, why each question matters, and which answers should make you slow down.

First, separate three things that get conflated

“Is it secure and reliable” is really three questions with three different owners, and a vendor can be strong on one while being vague on another.

Most security questionnaires cover the first column well, the second partially, and the third almost not at all. In a charging business the third column is where the real operational risk sits, because a platform outage can leave a driver standing at a connector.

Encryption and data handling

• Is traffic encrypted in transit on all three paths? Not just the operator dashboard - the driver app and the charger's own OCPP connection too. The charger link is the one that gets overlooked, and it is the path carrying meter values you will later bill against.
• Is data encrypted at rest, and which data stores does that cover? “Supported data stores” is a normal and honest answer; “everything, always” with no qualification usually means nobody checked.
• How are secrets and credentials managed? They should live in a dedicated secrets system, separate from application data - not embedded in configuration files or source code.
• Where does data physically reside, and can that be constrained? If in-country residency is a regulatory or policy requirement for you, this needs to be answered before commercial terms, not after. It is also the question most likely to change which deployment model you end up choosing.
• Who at the vendor can see our production data, and under what controls? Support and engineering need some access to help you. Ask whether it follows least-privilege, whether it is logged, and whether it is reviewed.

Identity, access and tenant isolation

• Can we federate to our own identity provider over SAML or OIDC? Covered in depth in enterprise SSO for charging platforms, including the role-mapping follow-up that matters as much as login itself.
• Is access role-based, and can roles be scoped to part of the network? A maintenance contractor should not hold the same authority as your operations lead - see roles, permissions and audit trails.
• If the platform is multi-tenant, how are tenants isolated? Ask at which layer - data and configuration - and then ask to see a partner tenant's login during evaluation rather than accepting a description. This matters enormously if you plan to run franchise or partner operations, and it is the core of what multi-tenancy actually means.
• Are API credentials scoped and revocable independently? An integration that only reads sessions should not hold a credential that can stop one - the reasoning is in APIs, webhooks and event streams.
• Is every administrative action logged at the request level, including failed attempts? And can those logs be filtered and exported, with a stated retention period? Your auditors will not log into the operator console.

Availability: get the number, then read what it covers

Ask for the uptime commitment in writing, in the contract, not as a figure on a slide. Then ask the three follow-ups that determine whether the number means anything:

• What is excluded? Scheduled maintenance windows are usually carved out of the calculation. That is standard - but you need to know how much notice you get and whether windows can be scheduled outside your peak charging hours.
• How is downtime measured, and by whom? A platform that measures its own availability from inside its own network will report better numbers than your drivers experience. Ask whether there is a public status page and an incident history you can read before signing.
• What is the remedy? Most SLAs pay service credits, which are typically small relative to the revenue an outage costs you - see the real cost of charging downtime. The credit is not compensation; it is a signal of how seriously the vendor takes the commitment.

The charging-specific question: what happens to a live session?

This is the question that separates a charging platform evaluation from a generic SaaS one, and the one most buyers forget to ask. If the connection between a charger and the back office drops - a platform incident, a site network failure, a mobile signal problem at a remote location - what happens to the driver who is already plugged in and charging?

The answer you want is that the session continues and reconciles afterwards, not that it terminates. A platform where a back-office interruption strands a mid-session driver has converted an infrastructure problem into a customer-facing incident and a refund. Ask specifically:

• Does an in-progress session keep delivering energy during a loss of connectivity?
• Are session records buffered on the charger and reconciled when the link returns, so you can still bill accurately?
• Can a new session start while the link is down, and if so, how is it authorized and priced?
• What does the driver see in the app during that window?

Note that some of this depends on the charger firmware as much as the platform, which makes it a question to put to both vendors rather than only the software one.

Backup, recovery and getting your data out

• What are the recovery objectives? How much data could be lost in a worst case (RPO), and how long would restoration take (RTO). Ask for numbers.
• When was a restore last actually tested? A backup schedule is a policy. A tested restore is evidence. These are not the same thing, and the gap between them is where real incidents live.
• How do we get our data out, on our own initiative, in a usable format? This is both a resilience question and an exit question. A platform you cannot export from is a platform you cannot leave, which quietly becomes a commercial term rather than a technical one.

Monitoring, and whose problem a fault is

Charging operations have an unusual monitoring boundary: the platform can be perfectly healthy while a charger in the field is broken, and the buyer experiences both as “the system is down.” Ask how the vendor distinguishes the two, whether charger-level connectivity and faults are monitored and alerted on as first-class signals, and whether alerts reach your operations team rather than only the vendor's. The metrics worth tracking on your side are in uptime and reliability metrics.

Secure development and vulnerability handling

• Do code changes go through review before release, and do releases roll out in stages? Staged rollout is the difference between a regression affecting one cohort and a regression affecting every customer at once.
• Are dependencies tracked and kept current? Most real-world compromises arrive through a known vulnerability in an unpatched dependency, not a novel attack.
• Is there penetration testing, and can we see a summary or letter of attestation? Expect the summary under NDA rather than the full report - that is normal.
• Is there a published way to report a vulnerability, and a stated response commitment? A vendor with a security contact address and a disclosure practice has thought about this before you asked.

Compliance: insist on the difference between “aligned” and “certified”

This is the single most useful piece of vocabulary in a security review. “Aligned with ISO 27001” means the vendor has built its practices against that framework. “ISO 27001 certified” means an accredited external auditor verified it and issued a certificate with a scope statement and an expiry date. Both can be legitimate positions; they are not interchangeable, and a vendor that blurs them in a sales conversation is telling you something.

Ask for the precise wording, and where a certification or attestation exists, ask for the scope - which entity, which systems, which deployment model - and the date. Certifications and reports commonly vary by deployment, and are usually shared under NDA rather than published. To be explicit about our own position: CarChargeOS describes its practices as aligned with ISO 27001, and specific certifications, attestations and reports vary by deployment and are available to enterprise customers under NDA. Apply the same question to us that you would to anyone else.

Shared responsibility: know which half is yours

No platform can secure what it does not control. On a charging network the boundary runs roughly here:

A vendor who states this boundary plainly is easier to work with than one who implies they cover everything. The second answer is more comfortable in a sales meeting and less useful during an incident.

Five answers that should slow you down

• “We're fully compliant.” With what, scoped to what, verified by whom, expiring when? Compliance without a noun is marketing.
• An uptime figure with no contract behind it. If it is real, it can go in writing.
• “Tenants are separated by permissions.” Permissions are configuration, and configuration can be changed by mistake. Ask about isolation at the data layer.
• No answer on live-session behavior during connectivity loss. Either it has been designed for or it has not; vagueness here usually means the latter.
• Reluctance to discuss past incidents. Every platform that has run long enough has had incidents. A vendor who can describe one, and what changed afterwards, is demonstrating process. A vendor who claims none is either new or not being straight with you.

CarChargeOS publishes its security practices - infrastructure and hosting, encryption, identity and access, multi-tenant isolation, auditability, availability and resilience, monitoring, secure development, and the shared-responsibility boundary - on the security page, with the platform-level overview on the platform page and deployment options on the enterprise page. For anything your security team needs that those pages don't cover, get in touch and we will tell you what applies to your evaluation.

Frequently asked questions