ISO 27001 consultants for SaaS and cloud businesses

For a SaaS business the certificate is almost always a sales document before it is a security one. It arrives because an enterprise buyer’s vendor-risk team asked for it, which means the thing that matters most is not whether you have it but what the scope on it says.

The questionnaire arrives before the certificate does

For most SaaS companies the sequence is not “get certified, then sell”. It is a security questionnaire landing mid-deal, a two-week turnaround, and someone in engineering losing a fortnight to a spreadsheet. The certificate is what you buy so that the next one is cheaper.

It is worth being realistic about how much cheaper. A certificate does not end questionnaires. Enterprise vendor-risk teams still send them, and they still contain questions the certificate does not answer: where data is processed and stored, who your sub-processors are, what your recovery time objective is, whether you have had a breach. What changes is that a large block of the questionnaire — governance, risk management, access control, incident response, staff training, supplier management — can be answered from evidence that already exists, by whoever owns the ISMS, rather than reconstructed by an engineer each time.

That reframes the business case in a way finance teams find easier to accept. The return is not a certificate on a website. It is the difference between a fortnight of senior engineering time per enterprise deal and an afternoon of it, multiplied by however many of those deals you expect.

Two practical notes. Keep a current sub-processor list, with what each one does and where: it is asked for in almost every questionnaire and it is also an Annex A supplier control, so it is one artefact doing two jobs. And keep the answers themselves somewhere versioned, because the inconsistency between two questionnaires answered six months apart by different people is what turns a routine review into a call.

The scope on the certificate is what your customer reads

A certificate names what was audited. For a product company that is the single most consequential decision in the whole exercise, and it is taken early, usually before anyone has explained what it will mean.

Certify the company and everything is in: the marketing team, the finance system, the office. The headcount is your whole payroll, so the audit-day band is higher and the audit costs more. Certify the product — the platform, the engineers who build it, the systems it runs on — and the headcount is smaller, the audit is shorter, and the certificate says exactly the thing your customer wanted to know.

The failure mode is a scope drawn narrowly to save money that then excludes something the customer assumed was covered. Support, for instance: if your support team can see customer data and support is outside the scope, a vendor-risk reviewer who reads the schedule will notice. Draw the scope around what the customer is buying, not around what is cheapest to audit.

The cloud control that did not exist before 2022

A.5.23, information security for use of cloud services, is one of the controls introduced in the 2022 edition. In the previous edition cloud was handled as ordinary supplier risk; now it has its own control covering the acquisition, use, management and exit from cloud services.

Exit is the part that catches SaaS businesses, because it is the part nobody has thought about. An auditor asking how you would leave your primary cloud provider is not expecting a migration plan with dates. They are expecting evidence that the question has been considered and that the dependency is understood, and “we would be in serious trouble” delivered confidently, with a documented assessment behind it, is a better answer than a fictional plan.

The related trap is the shared responsibility boundary. Your cloud provider’s own certificate covers the provider’s controls, not yours. You cannot inherit compliance from it, and an auditor will ask which controls you rely on them for, how you assured yourself of that, and what you do that they do not.

Multi-tenancy, environments, and real data in the wrong place

Two technical questions come up in almost every SaaS audit and both are worth settling before Stage 1 rather than during it.

Tenant separation. How is one customer’s data kept from another’s, and how do you know it works? The answer is architectural and the evidence is usually a test. A team that can show an automated test proving cross-tenant access fails is in a much stronger position than one relying on an assertion about how the code is written.

Production data in non-production environments. A.8.11, data masking, is another of the new controls, and this is where it lands. Copying a production database into staging to reproduce a bug is common, understandable, and hard to defend to an auditor if it is undocumented and unbounded. Either stop doing it, or have a controlled, time-limited, approved process for when it happens.

ISO 27001 and SOC 2 are not the same shape

Most UK SaaS companies selling into the United States meet both, and they are frequently described as interchangeable. They are not, and the difference decides which one you should do first.

ISO 27001 certifies a management system: it asks whether you have a process for identifying and treating information security risk, and whether it is running. It is audited by an accredited certification body and the output is a certificate. SOC 2 is an attestation by an accountancy firm about controls against the Trust Services Criteria over a period, and the output is a report that the reader has to read.

Practically: a European or UK enterprise buyer usually asks for ISO 27001; a United States buyer usually asks for SOC 2. If both are coming, the controls overlap heavily and the evidence is largely reusable, which is the strongest case for a compliance platform that handles both. What does not transfer is the management system itself — the risk assessment, the Statement of Applicability and the management review have no SOC 2 counterpart.

What this does not change

Whatever sits on top, the arithmetic underneath is the same for every sector. Audit days come from ISO/IEC 27006 audit time table, reproduced in full in an accredited certification body's published audit-duration procedure (QSI-TL.04 rev 21) and are a function of the people inside your scope, your sites and your complexity. Surveillance is one third of the initial audit every year and recertification is two thirds in year three. Your certification body cannot be your consultant, and cannot do the internal audit clause 9.2 requires.

Work out the cost for your headcount, or see the full audit-day table.

Common questions