On 1 September 2026, Pro-Test Consulting Private Limited — our India-based delivery entity — achieved ISO 27001:2022 certification.
We could have led with the badge. Instead, here’s the reasoning behind it, because the reasoning is the part that actually matters to the people evaluating us.
Why certify at all?
Software testing means handling client code, test data, and often production-adjacent environments. For our regulated clients — fintech, healthtech, insurtech, govtech — that’s not a nice-to-have. It’s the first question procurement asks, and it’s usually the question that stalls a deal if the answer isn’t documented.
We’d been operating with strong internal security practices for years. What we didn’t have was the external, audited proof that those practices meet a recognised international standard. ISO 27001:2022 closes that gap.
What it actually covers?
The certification maps to how we work day to day:
- Access control — who can touch client code, test data, and environments, and how that access is granted, reviewed, and revoked
- Data handling — how client data is stored, transmitted, and disposed of across our delivery lifecycle
- Incident response — documented processes for identifying, escalating, and resolving security incidents
- Continuous improvement — regular internal audits and management review, not a one-time checkbox
The accurate way to say this.
The certificate sits on Pro-Test Consulting Private Limited, our India-based delivery entity — not on Pro-Test Technologies as a whole. So we say it this way, and we’ll keep saying it this way:
“Our delivery operations are ISO 27001:2022 certified.”
Not “Pro-Test Technologies is ISO 27001 certified.” That distinction matters. UK buyers doing due diligence will pull the certificate and see a different legal name and country than the entity they’re contracting with — better they hear the accurate framing from us first than discover a discrepancy later.
Why this matters beyond the badge?
We’ve written before about why independent QA needs to prove its own trustworthiness before it can be trusted to test anyone else’s product — the same argument sits underneath our take on [what FCA compliance actually requires from a testing process]. Certification is one input into that. Not the only one — but it’s now a documented one, rather than a claim we’re asking clients to take on faith.
If you’re evaluating a testing partner and security posture is part of that decision, ask to see the certificate and ask what’s in scope. We’d rather you ask than assume.
Questions about our security practices or what’s in scope for the certification? Reach out — we’re glad to walk through it.