ISO 27001 readiness checklist for SaaS.

ISO 27001 is the international standard for an Information Security Management System (ISMS), and it is the certification your EU enterprise buyers will ask about once SOC 2 is already on file. The pattern for a 50 to 2,000-employee SaaS is identical: the customer’s security review asks for a SOC 2 report, you provide it, and a year into the contract their DPA team asks for “a certified ISMS” or, more commonly, ISO 27001 alignment alongside ISO 27017 / ISO 27018 if you handle their data in the cloud. By the time the procurement team files the request, your auditor is booked at four weeks out and your security lead is rebuilding a control map from scratch.

That is the certification this post is preparing you for. ISO 27001 stacks on top of SOC 2 rather than replacing it: the SOC 2 report still answers “what controls do you operate,” and ISO 27001 adds “how is the ISMS governed” — clauses 4 through 10 for the management system, Annex A for a catalogue of 93 controls you scope in or out of via a Statement of Applicability. Run both, mapped to the same evidence trail, and you walk into one audit cycle already prepared for the next.

The SaaS ICP for this post is the same one the rest of Pactward’s playbook is written for: 50 to 2,000 employees, EU enterprise customers, and a security lead reading this on a Monday morning before a steering committee meeting on Wednesday. The checklist below is the steering deck and the audit-prep backbone in one.

Clauses 4 to 6 are the management-system half of the standard. They don’t map to specific access controls or log sources — they map to how the company runs the ISMS, who is on the hook for it, and how it scopes itself against the business. Get this wrong and the auditor writes a finding on day one of the audit.

Context of the organization (4.1 – 4.2)

A short document — usually two to four pages — defining the ISMS’s scope, the issues and interested parties that shape it, and which legal / regulatory / contractual obligations the system is built to satisfy. The auditor reads this first and uses it to scope the rest of the audit. For a SaaS the scope statement almost always names the production platform, the corporate IT estate, and the cloud accounts it runs in.

Leadership commitment (5.1 – 5.3)

Top management names a management representative, signs off on the information security policy, and assigns roles. The auditor will interview the management representative and ask “how does leadership know controls are operating” — the answer needs to cite an actual feedback loop, not a slide from the last board meeting.

Planning (6.1 – 6.3)

The risk assessment and risk treatment methodology live here. Every risk gets a likelihood-and-impact score and a treatment decision (mitigate, transfer, accept, or avoid). For SaaS this is a 10-to-30-row register, not a 200-row one — the auditor wants a defensible methodology, not exhaustive coverage.

Statement of Applicability framing

The SoA is technically Annex A control A.5.10, but it is the document that ties the whole ISMS together. It is the case your certifying auditor will accept or reject on.

Do this in Pactward · clauses 4 to 6 mapped to live evidence

Clauses 7 to 10 are the “continuous improvement” half. They cover how the ISMS runs day-to-day, how you measure whether controls are operating, how internal audits feed back, and how nonconformities are remediated. ISO 27001:2022 added explicit hooks for “documented information” to replace the old “documents and records” terminology — the easiest read of that change is “evidence, broaden and operationalize.”

Resources, competence, awareness (7.1 – 7.3)

People doing the work need to be competent — and the auditor wants evidence that you checked. Role definitions, training records, and on-the-job competence notes are enough; the auditor is not asking for a learning management system, just evidence that someone with the right skills actually did the work.

Documented information (7.5)

ISO 27001:2022 dropped the noun “documents and records” and replaced it with “documented information” that the organization creates and maintains. This is a cleaner framing of the same requirement: version control on policies, retention on evidence, and access control so the wrong people can’t edit policies.

Operational planning and control (8.1)

A short clause that ties planning (clause 6) to the work the operations team is actually doing. The auditor expects to see the operational plan document, plus evidence the controls were implemented as planned — usually a sampling exercise across the audit window.

Performance evaluation and internal audit (9.1 – 9.3)

The internal audit programme that gives the standard its assurance value. Plan, competence, sampling, and reporting all live here. The auditor will sample one or two internal audits and look for evidence the results actually fed into management review.

Nonconformity and continual improvement (10.1 – 10.2)

A nonconformity is a control that didn’t work. The clause asks for a record of what was learned, what was corrected, and how the “consequence” was contained — plus evidence the same nonconformity was prevented from recurring. This is where a continuous monitoring layer pays off: drift caught the same day is usually a minor correction; drift discovered at the audit is a finding.

Annex A organizes ISO 27001’s 93 controls into four families. The organizational family (A.5) is the table-setting layer: it names the company’s policies, the roles and responsibilities that operate them, and the Statement of Applicability that the whole certification hangs on.

Information security policies (A.5.1 – A.5.4)

A short set of topic-specific policies — information security, access control, change management, incident response, business continuity, supplier security — version-controlled and approved at the right level. Auditor expects 8 to 15 policies, not the 200-page “policy manual” of two decades ago.

Roles and responsibilities (A.5.5 – A.5.8)

Roles named, roles covered, and the segregation of duties between them. The compliance lead owns the ISMS; the security team owns the controls; engineering owns the implementation. The auditor wants RACI-style evidence, not a “see the org chart” hand-wave.

Statement of Applicability (A.5.10)

The case that closes the certification: every Annex A control, marked Applicable or Not Applicable, with a justification and a reference to the implemented control. The SoA is what the auditor grades against — the better it is, the less work the audit itself costs.

The people controls are short. ISO 27001:2022 folded most of them into two control groups: the screening and on / off-boarding of people who handle confidential information, and the awareness / training programme that keeps security top of mind.

Screening and on/off-boarding (A.7.1 – A.7.4)

Background checks at hire, access reviews on role change, and a clean termination process that closes all accounts before the user’s last day. The on / off-boarding trail is auditable evidence for access control families in clauses 5, 9, and Annex A.9 — the same evidence trail serves three separate controls.

Security awareness (A.7.6 – A.7.8)

Annual security awareness training plus targeted role-specific training for engineers, customer support, and leadership. Phishing simulations on a defined cadence are not required by the standard but are the cheapest, most defensible evidence the auditor will sample.

Physical controls inherit from the data center and the cloud provider. ISO 27001 recognises this — a SaaS that runs entirely in AWS, GCP, or Azure, with no on-premises footprint, inherits the bulk of Annex A.8 from the provider’s own ISO 27001 certification.

Physical perimeters (A.8.1 – A.8.5)

The data center controls you inherit from your cloud provider’s SOC 2 and ISO 27001 reports. The non-cloud variant is the home office and corporate offices — the auditor will ask for evidence those have controls too, even if it’s a small office with a fob reader and a closed-circuit camera.

Equipment and disposal (A.8.8 – A.8.13)

For SaaS this is the laptop / mobile fleet: MDM, encryption at rest, secure boot, and a budgeted refresh cycle tied to the OS vendor’s support window. Equipment disposal needs a documented wipe-and-dispose path — the auditor will sample one or two and ask for the certificate.

Annex A’s technological family is where the standard’s expectations intersect with the engineering organisation. The auditor samples more controls here than anywhere else — this is the part that pays for a continuous watch plane to feed the evidence trail on its own. Seven controls live in this section.

Access control (A.9.1 – A.9.6)

Identity, authentication, authorisation, and the access reviews that prove the governance is working. SSO plus a centralised identity provider, MFA on every privileged account, just-in-time provisioning for break-glass access, and quarterly access reviews with documented sign-off.

Cryptography (A.9.7 – A.9.10)

A short policy on what gets encrypted, with what algorithms, at what key rotation cadence. TLS 1.3 on the wire, AES-256 at rest, KMS-managed keys, and a key rotation schedule that doesn’t outrun the people maintaining it.

Monitoring and event logging (A.9.11 – A.9.15)

Centralised logs, tamper-evident retention, and the dashboards / alerts that prove the monitoring is operating as designed. The auditor expects evidence the analytics is firing and the alerts are reviewed on a defined cadence.

Secure development (A.9.16 – A.9.20)

The SDLC controls that pair with Annex A.5: change management, code review, dependency scanning, and a documented release pipeline. The auditor pairs this with the access controls on production deploys to form a complete picture of the engineering organisation.

Secrets and configuration (A.9.21 – A.9.23)

Secrets in a managed KMS, scanned for hardcoded credentials, rotated on a defined cadence, and never committed to source. Configuration baseline as code, validated against the running estate on every change.

Supplier relationships (A.10.1 – A.10.8)

The supplier controls that became A.10 in ISO 27001:2022 — a separate family that the auditor now grades with more rigor than the 2013 version. The work here is a vendor register, risk tiers, due-diligence evidence on the critical vendors (SOC 2 or ISO 27001 reports, sub-processor lists, security questionnaires), and a contractual SLA that includes notification on incident.

Availability, change, and backup (A.11 – A.12)

The change-management, capacity, and back-up controls that round out the technological family. Multi-region backup, RPO / RTO defined and tested, change advisory board (or its lightweight equivalent), and a documented patch-and-update cadence tied to severity.

Do this in Pactward · every Annex A control mapped to live evidence

The Statement of Applicability is the certification’s spine. A defensible SoA names the 93 Annex A controls, marks each Applicable or Not Applicable, and ties Applicable controls to the implemented control and the evidence that proves it. The auditor grades the audit against the SoA — when the SoA is comprehensive, the audit cycle is short, and what’s left is the evidence the auditor’s own sampling exercise covers.

The most underrated part of the SoA is currency. ISO 27001:2022 added a control that didn’t exist in the 2013 version, dropped others, and reorganised the rest by theme. When the standard updates, the SoA needs to update with it, and the changes need to be reflected in the controls the team operates. A continuous watch plane keeps the SoA current automatically — new controls surface as soon as the published standard does, and the evidence trail that proves them is already in place.

Do this in Pactward · open the ISO 27001 framework and SoA

The pattern above fits a four-week audit cycle once the ISMS is mature. The first certification is the hard one. Pactward’s platform collapses the lift at three places the team usually strains to staff: the controls the standard doesn’t provide a default for, the evidence trail the certifying auditor asks for, and the vendor register the 2022 update made mandatory.

Custom controls for the standards you operate

The 93 Annex A controls are the floor, not the ceiling. Pactward’s custom-controls and custom scan-rules layer adds the controls your specific ISMS operates — the ones the standard nods at but doesn’t enumerate — and ties them to the evidence trail they map to. Where the enabling IT team has a bespoke change-review workflow for emergency changes, for example, a custom control models it without forcing the team to spin up a separate GRC tool to capture the signal.

Do this in Pactward · start with a custom control scaffold

Evidence export that survives the audit

The auditor’s favourite question is “show me the evidence.” Pactward exports the evidence trail as a PDF the certifying auditor can ingest — control ID, control implementation reference, the run that produced the finding, and the remediation that closed it. The export is what closes the audit without a six-week follow-up cycle, and it drops straight into the audit binder.

Do this in Pactward · export the audit evidence binder

Vendor risk register that holds up

Annex A.10’s 2022 updates made a maintained vendor register a hard requirement. Pactward ships the register with risk tiers, sub-processor graph, the SOC 2 / ISO 27001 reports for your critical vendors, and a contractual-SLA checklist that flags gaps before the auditor does. The register is what makes the “supplier relationships” control group cheap to evidence and easy to keep current.

Do this in Pactward · open the vendor risk register

Round three of the certification is where continuous monitoring pays its real dividend. The clauses 4 to 10 work the auditor sampled during the first audit is the same evidence the second audit grades against, and the controls that drifted in the interval get caught before the auditor does. The certification is the milestone — the watch plane is what makes the next one cheaper than the first.