Industries
Cyber security for it, ites & saas.
Product companies and service providers who need to prove security to their own enterprise customers.
What is actually going on here
For a SaaS company security stops being an IT concern the moment an enterprise buyer sends a questionnaire. It becomes a sales problem, and a slow one. Deals sit still while somebody hunts for a penetration test report that is eighteen months old and covers a version you no longer run.
The engineering side has its own shape. You ship continuously, so a point in time test ages badly. Your architecture is multi-tenant, which means the single worst finding available is not a broken login, it is one customer reading another customer's data. That is the class of bug we hunt first.
Most of our SaaS work is a mix: testing that keeps pace with your release cycle, and the certification that unblocks procurement. Done together they cost less than done separately, because the evidence is the same evidence.
Who regulates you, and what they want
Tick the ones that bind you and we will pull together the evidence each of them actually asks for. Nothing is sent anywhere.
Pick one or more above to see what they expect of you.
What goes wrong in this sector
Tenant isolation failure
The defining SaaS vulnerability. An object identifier that is not scoped to the tenant, a cache key that omits the tenant, a background job that queries across tenants for convenience. Each one is invisible in a single tenant test and fatal in a multi-tenant product.
API abuse and broken object level authorisation
Your API is larger than your UI and often tested less. The failure is authorisation rather than authentication: the caller is logged in, they are just reading a record they should not. Automated scanners almost never find this.
Supply chain and dependency compromise
A typosquatted package or a compromised maintainer account puts your code in the attacker's hands before it reaches production. The control is a real inventory and pinned, verified builds, not a quarterly scan.
CI/CD and secret exposure
The pipeline usually has production credentials and looser access control than production. We routinely find deployment tokens in build logs, and a build log is not treated as sensitive by anyone.
How we work in this sector
- 01
Break tenancy first
We start every SaaS engagement with two accounts and a single question: can one see the other's data. Everything else waits until we have an answer.
- 02
Test the API surface properly
We work from your specification where you have one and from traffic where you do not, then test authorisation per object and per role rather than sampling endpoints.
- 03
Fit the release cycle
For teams shipping weekly, an annual test is theatre. We scope continuous or per-release testing so coverage tracks the code rather than the calendar.
- 04
Turn it into sales evidence
The output is written so it can go to a customer under NDA: an executive summary that answers a procurement question, with the technical detail behind it.
What we actually keep finding here
Not a threat list copied from a report. These are the patterns that recur across our own engagements in this sector, with an honest note on how often. Where we do not have a precise number we say so rather than inventing one.
- Often
One tenant able to reach another tenant's data
An object identifier not scoped to the tenant, a cache key that omits it, or a background job querying across tenants for convenience. Invisible in a single-tenant test and fatal in a multi-tenant product.
- Most engagements
Authorisation enforced in the interface, not the API
The button is hidden and the endpoint still answers. The caller is legitimately logged in; they are simply reading something that is not theirs.
- Often
Production credentials in the build pipeline
Deployment tokens in build logs, which nobody treats as sensitive, on a system with looser access control than production itself.
- Most engagements
SOC 2 evidence that cannot be produced retrospectively
Type II assesses controls over a period. Teams discover in month ten that the evidence for months one to nine was never collected.
Questions worth asking any provider in this sector
Including us. If a provider cannot answer these clearly, that tells you more than any capability slide will. We would rather you asked them than took our word for it.
- 1
Will you test tenant isolation specifically, with two accounts, as the first thing you do?
- 2
How will testing keep pace with weekly releases rather than being an annual event?
- 3
Will you test the API surface per object and per role, or sample endpoints?
- 4
Can I share a version of the report with an enterprise customer under NDA?
- 5
If we do ISO 27001 and SOC 2, will the evidence be gathered once or twice?
What we deliver in this sector
- Web, mobile & SaaS platform testing
- API & microservices security
- SOC 2 and ISO 27001 readiness
- Cloud security & configuration review
- Supply chain & vendor risk assessment
- Identity & access management review
- DevSecOps & secure SDLC implementation
- Customer security questionnaire support
Proof
SOC as a Service protecting the CSM Technologies estate
Work in this sector
Named engagements where the client has agreed to be named, and anonymised ones where they have not, which is most of them. Named references are available under NDA.
- Capital Markets
Protecting 1.7M+ users with SEBI compliance for Marketwolf
SEBI cyber security and cyber resilience framework compliance for a high-volume retail trading platform.
1.7 million+ users
- IT Services
CSM Technologies relies on CYQER to protect its IT assets
Managed SOC-as-a-Service delivery giving unified detection and response across the client's IT estate.
Enterprise estate
- Client withheld
Product company, continuous testing model
- Scope
- A team shipping several times a week, where an annual test would have aged before the report landed.
- What we found
- Two releases in the baseline period had changed authorisation logic without any security review.
- Outcome
- Targeted testing tied to changes touching authentication, authorisation or tenancy, rather than to the calendar.
- Client withheld
B2B SaaS platform, pre-enterprise procurement
- Scope
- Multi-tenant product with an API larger than its interface, tested ahead of a customer security review.
- What we found
- A background job that queried across tenants for convenience, exposing one customer's records to another.
- Outcome
- Fixed and re-tested within the sprint, and the summary report used to close a stalled enterprise deal.
- Client withheld
Technology services firm, dual certification
- Scope
- ISO 27001 and SOC 2 Type II run together rather than sequentially.
- What we found
- Substantial overlap in evidence, and no continuous collection in place for the SOC 2 observation window.
- Outcome
- One control set mapped to both, evidence collection automated, and the observation window started early enough to hold the date.
Questions we get asked in this sector
SOC 2 or ISO 27001 first?
Follow your buyers. North American enterprise procurement asks for SOC 2; European, Indian and Middle Eastern buyers more often ask for ISO 27001. If you sell to both, do ISO first and map to SOC 2, because the ISMS gives you the evidence machinery the SOC 2 observation window then feeds on.
We deploy several times a week. How does testing keep up?
It cannot, if testing is an annual event. We run a baseline deep test, then lighter targeted testing on changes that touch authentication, authorisation or tenancy. Most releases do not need a retest and we will tell you which ones do.
Can we share your report with our customers?
Yes. We write a summary version intended for exactly that, so you are not forwarding a document full of unfixed technical detail to a prospect.
How long does ISO 27001 take from a standing start?
Six to nine months for most SaaS companies of under 200 people, and the gate is documentation maturity rather than technical work. Teams with good engineering practice and no written process are the common case and they are usually surprised by how much of the effort is writing.
Not sure where to start?
Book a 30-minute call with a senior engineer. We will walk through your current posture, the frameworks that bind you, and what a realistic programme looks like.