VAPT, ISO 27001 And SOC 2: The Security Evidence To Demand From Your Charging Software Vendor

VAPT, ISO 27001 And SOC 2: The Security Evidence To Ask Your Vendor For

Every charging-platform deal reaches the security questionnaire stage, and that is where a VAPT report, an ISO 27001 certificate and a SOC 2 report change hands. This guide is for the buying side of that stage at CPOs, eMSPs, fuel retailers and enterprises running a platform procurement: the IT or security reviewer who has to sign off, and the procurement lead who has to know what to request. The three documents are often treated as interchangeable boxes to tick. They are not. Each proves a different thing, over a different period, about a different scope.

This post stays on the evidence itself. API hardening is covered in our guide to secure EV charging API practices, charger and OT security in IEC 62443 for EV charging, and EU legal duties in NIS2 and EV charging. If your platform also takes card payments at the charger, the separate attestation for that is explained in PCI DSS and EV charging.

What A VAPT, ISO 27001 And SOC 2 Each Prove

Read them as answers to three different questions. A VAPT answers could someone break in when we last looked? ISO 27001 answers does this company run a managed security programme? SOC 2 answers did the controls actually work over months, according to an independent auditor?

VAPT report: a point-in-time test

Vulnerability assessment and penetration testing (VAPT) pairs an automated sweep for known weaknesses with a tester trying to exploit them by hand. CERT-In’s Comprehensive Cyber Security Audit Policy Guidelines (version 1.0, 25 July 2025) define penetration testing as actively testing components “to identify and exploit potential vulnerabilities”. That is a useful bar, because a scanner printout with a cover page is not a penetration test. A VAPT report describes the system on the dates tested, for the assets in scope, and nothing else. A clean result on a marketing website says nothing about the charger endpoint. Its value rests on three things: the scope, the method and whether a retest confirmed the fixes.

ISO 27001 certificate: an audited management system

ISO/IEC 27001:2022 certifies an information security management system (ISMS), meaning the policies, risk assessments and controls a company uses to run security. It does not certify a product. The 2022 edition lists 93 reference controls in Annex A across four themes: organisational, people, physical and technological. Certificates against the older 2013 edition lapsed when the transition period closed on 31 October 2025. ISO itself issues no certificates; independent certification bodies do. Check three things. First, the scope statement: does it name the charging platform and the teams that run it, or only a head office? Second, the Statement of Applicability: which Annex A controls apply, which were excluded, and why. Third, the certification body: it should be accredited by a national accreditation body. Certificates run on a three-year cycle with surveillance audits in between, so ask for the date of the latest one.

SOC 2 report: controls tested over time

A SOC 2 report is an attestation by a licensed CPA firm under AICPA standards. It is built on the Trust Services Criteria: security, availability, processing integrity, confidentiality and privacy. Security, the common criteria, is always included; the vendor chooses the rest, so read which ones it picked. For a platform your chargers will depend on for years, availability is the one to look for. A Type I report says the controls were suitably designed on a single date. A Type II report says they also operated effectively across an observation period, commonly three to twelve months. Type II is the one that matters. Because every report covers a past period, vendors fill the gap until the next one with a bridge letter, a management statement that nothing material has changed. No auditor stands behind it, so treat it as a promise rather than evidence.

How the three security artefacts differ.

Ask for these five documents:

1. The latest full VAPT report, under NDA, dated within the last 12 months.
2. The retest or closure report showing critical and high findings were fixed.
3. The ISO 27001 certificate with its scope statement and Statement of Applicability.
4. The SOC 2 Type II report and the current bridge letter, if the vendor has one.
5. The vulnerability management policy, with a remediation deadline per severity.

Scoping A VAPT For A Charging Software Stack

A charging platform has more doors than a typical SaaS product, and the riskiest one is the most often left out. Before reading any findings, check the scope against this list.

What the test should cover on a charging platform.

The OCPP endpoint deserves its own sentence. The Open Charge Alliance defines security profiles for the charger connection: profile 1 is HTTP basic authentication without TLS, profile 2 adds TLS on top of basic authentication, and profile 3 uses TLS with client-side certificates. A good report states which profiles the endpoint accepts and whether a charger can be pushed down to a weaker one. That is a direct test of the OCPP-compliant charging software you are buying.

Usually out of scope: charger firmware, local diagnostic ports and charger hardware. That is the charger OEM’s job, and that evidence should come from the OEM. A platform vendor whose test report claims to cover chargers it does not build deserves a follow-up question.

Authenticated versus unauthenticated testing

Unauthenticated, or black-box, testing shows what an outsider can reach. Authenticated testing logs in as a driver, a site host and an operator, then checks whether one can see or change another’s data. On a multi-tenant system, such as a white-label charging platform where several operator brands share one backend, tenant isolation is the finding that matters most. Only authenticated testing finds it.

Retest evidence

CERT-In’s guidelines expect a follow-up audit after vulnerabilities are closed, and a closure report confirming every finding was addressed. Ask for the same from any vendor, wherever the test was done. A first report full of open findings, with no retest, proves only that problems were found.

How To Read A VAPT Report

Go to the findings summary first. Each finding should carry a severity, and most testers use the Common Vulnerability Scoring System (CVSS), which scores from 0 to 10.

CVSS v3.x and v4.0 qualitative ratings, per NIST’s National Vulnerability Database. The right-hand column is a buyer’s rule of thumb.

CERT-In goes one step further: its guidelines require empanelled auditors to pair CVSS with the Exploit Prediction Scoring System (EPSS), which estimates how likely a weakness is to be exploited in the wild. Then check three things. Open versus closed: any critical or high finding open at the report date needs a dated fix. Remediation timelines: the vendor’s policy should commit to a deadline per severity, and the retest dates should show it was met. Method: the tools, test dates and test accounts used should be stated.

Red flags

• A report more than 12 months old, or older than the last major release. A three-year-old report describes a different product.
• A scope that omits the OCPP endpoint or the OCPI APIs.
• No retest or closure evidence.
• Only an executive summary, with a refusal to show findings even under NDA.
• Every finding rated low on a large platform, which usually means a narrow scope rather than perfect code.

Who Asks For What, By Market

Which document a buyer expects depends heavily on where the buyer sits. A vendor selling across regions should be able to produce all three; a vendor selling into one market may hold only the local standard.

Typical buyer expectations by region.

In India, CERT-In maintains a published list of empanelled auditing organisations, so a buyer can check the tester’s name directly. In the EU, the NIS2 Directive does not name a certificate, but in-scope operators must assess their suppliers’ security, and ISO 27001 is the shortest answer to that question. India’s separate legal duties for operators, such as incident reporting and log retention under CERT-In’s 2022 Directions, fall on the operator rather than on the vendor’s documents, and we cover them separately.

Time And Cost To Obtain Each

Timelines explain why vendors hold different documents. A VAPT on a defined scope takes weeks, including the retest. ISO 27001 needs an ISMS that has run long enough to produce records, then a two-stage certification audit, then annual surveillance. A SOC 2 Type II cannot exist until its observation period has passed, so a vendor that starts today cannot give you one for months. Cost scales with scope, and a missing document is not automatically a warning sign: a vendor without a SOC 2 may simply not sell in the US.

Putting The Evidence Into The Contract

Evidence collected at the questionnaire stage starts ageing the day the contract is signed. Three clauses keep it current: a right to receive each new VAPT and retest report at least annually; notice within an agreed window if a certificate lapses, is suspended or narrows in scope; and a commitment to fix critical and high findings within stated deadlines.

Apply the checklist above to every platform on your shortlist, ours included. YoCharge’s charging management platform runs across 6+ data centers on AWS, Google Cloud and Azure, with 99%+ uptime for operators in 25+ countries, and our team will walk your security reviewer through the questionnaire line by line.

Sources: CERT-In: Comprehensive Cyber Security Audit Policy Guidelines (25 Jul 2025) | CERT-In: Empanelled Auditing Organisations | ISO: ISO/IEC 27001:2022 | AICPA: SOC 2 | NIST NVD: CVSS severity ratings | ENISA: NIS Directive 2 | Open Charge Alliance: OCPP