ISO 27001 for SaaS: what actually matters in Stage 2
Most first-time failures are not technical. They come from a scope nobody can defend, a risk assessment written the week before the audit, and evidence that does not match the policy.
Stage 2 is where an ISO 27001 audit stops being about documents and starts being about whether you operate what you wrote down. Teams that fail rarely fail on a missing policy. They fail because the auditor pulls a thread and the management system behind it does not hold.
Scope you can defend in a sentence
The single most common problem is a scope statement written to sound impressive rather than to be accurate. If your Statement of Applicability excludes physical security because you are remote-first, that is fine, but you need to say so in terms of the ISMS boundary, and you need it to be consistent with the asset inventory, the risk register and the supplier list.
Draw the boundary around the product, the environments that run it, and the people who can touch either. Then check that every other document agrees with that boundary.
A risk assessment with dates on it
Auditors can tell when a risk register was populated in one sitting. Real risk management leaves a trail: risks raised at different times, treatment decisions with owners and dates, some risks accepted with a written rationale, some reassessed after an incident or an architecture change.
- Tie risks to real threats against your actual architecture, not to a generic library
- Record who accepted each residual risk, and when
- Show at least one review cycle before the audit, a register with a single creation date is a red flag
- Link high risks to the controls in your Statement of Applicability that treat them
Evidence that matches the claim
If your access control policy says quarterly access reviews, the auditor will ask for the last two. If your secure development policy says security testing happens before major releases, they will ask which release and want the report.
The fastest way to fail Stage 2 is to write a policy describing the company you intend to become.
Write policies that describe what you do today, and improve the practice before you improve the document. A modest ISMS that is genuinely operated passes; an ambitious one that is not, does not.
Where penetration testing fits
Annex A 8.8 covers management of technical vulnerabilities and 8.29 covers security testing in development and acceptance. Neither names a penetration test outright, but evidencing them convincingly without one is difficult. Auditors expect to see independent testing, a remediation record, and, this is the part teams miss, verification that the fixes worked.
Schedule the test early enough that you can remediate and retest before Stage 2. A report full of open criticals is worse evidence than no report at all.