From Enterprise Blocker to Certified: How Lean SaaS Teams Build an ISMS and Clear ISO 27001

One security questionnaire from an enterprise prospect can make ISO 27001 the highest-priority item on a founder's roadmap overnight. The deal is real, the champion is on board, and then procurement sends a 40-item vendor assessment with a single checkbox near the top: "Is your organization ISO 27001 certified?" The answer determines whether legal reviews a contract or files a pass.

For pre-seed to Series A teams, ISO 27001 has shifted from a nice-to-have to a sales gate. At Folksoft, we work with lean SaaS teams at exactly this inflection point, combining continuous evidence automation with a dedicated compliance analyst who builds the Statement of Applicability, risk register, and pre-audit checklist alongside your team.

Three decisions shape how fast you move: how much internal Governance, Risk, and Compliance (GRC) capacity your team realistically has, how much timeline pressure the sales pipeline is generating, and whether you already carry a SOC 2 report or are starting from zero. This guide addresses all three.

1. What ISO 27001 Actually Requires

ISO 27001:2022 is a management system standard. It defines how an organization establishes, implements, maintains, and continually improves an Information Security Management System (ISMS). The standard is organized around clauses 4 through 10, covering organizational context, leadership, planning, support, operation, performance evaluation, and improvement.

Annex A accompanies the main clauses and lists the controls an organization may need to implement. The 2022 revision brought the total to 93 controls organized across four themes:

• Organizational controls: Policies, roles, threat intelligence, and supplier relationship requirements.
• People controls: Screening, awareness training, and offboarding procedures.
• Physical controls: Physical security perimeters, equipment protection, and clear-desk requirements.
• Technological controls: Identity management, malware protection, logging, and vulnerability management.

A critical point: not every organization must implement all 93 controls. Each organization's risk assessment determines which controls are applicable. The result is documented in the Statement of Applicability (SoA), which lists every Annex A control, states whether it is applied or excluded, and records the reasoning behind that decision. The SoA is one of the most scrutinized documents in any certification audit.

Note that the 2013 version of the standard included 114 controls. If your team is working from older templates or consulting guides, verify that they have been updated to the 2022 revision before building ISMS deliverables.

The Two Certification Audit Stages

Certification requires two formal audit stages conducted by an external accredited body:

Stage 1 (Documentation Review): The auditor reviews your ISMS documentation, including scope, policies, SoA, risk register, and management review records, to confirm the system is documented and appears implementable. Gaps identified here must be addressed before Stage 2.

Stage 2 (Controls Testing): The auditor verifies that your documented controls are actually operating. This involves interviews, log reviews, and spot-checks across technical and procedural controls. Passing Stage 2 results in the issued certificate.

After initial certification, the cycle continues: annual surveillance audits verify that controls remain effective, and a full recertification audit is required every three years.

2. Choosing a Certification Body

The certificate your team receives is only as credible as the body that issued it. Certificates from bodies accredited through the International Accreditation Forum (IAF) Multilateral Recognition Arrangement (MLA) are recognized across international markets. The IAF maintains the MLA framework, which sets the recognized baseline for globally accepted certification through a network of signatory accreditation bodies.

Before contracting with any certification body, verify its accreditation status using iafcertsearch.org, which the IAF maintains as a real-time database of accredited certificates. A certification body that is not findable through that database may not be covered by the MLA, which means customers or partners in other markets may not recognize the certificate it issues.

When evaluating shortlisted certification bodies, consider three factors:

• SaaS-sector experience: Auditors familiar with cloud-native architectures understand that asset inventories include container registries, SaaS dependencies, and managed services alongside traditional infrastructure. Relevant sector experience reduces friction during Stage 2 spot-checks.
• Remote audit support: Most early-stage teams operate with distributed headcount. Confirm that the body supports remote audit procedures for both Stage 1 and Stage 2 before signing the engagement letter.
• Target-date availability: Certification bodies have limited auditor bandwidth. If a sales deadline is driving your timeline, confirm the body can schedule both stages within your required window before you commit.

Audit fees for Stage 1 and Stage 2 combined typically range from $5,000 to $35,000, depending on the certification body, company size, and ISMS scope. These fees are paid directly to the certification body and are always separate from compliance platform or consulting costs. Budget separately for the ongoing annual surveillance audits that follow initial certification.

3. Choosing a Compliance Partner

The compliance partner market offers three distinct service models:

Documentation consultants produce policy suites, risk registers, and SoAs on a project basis. This model works well for teams that already have a security-aware engineering lead who can own implementation and evidence collection independently after handoff.

Automation platforms integrate with your cloud, identity, and Human Resources Information Systems (HRIS) to continuously collect evidence and map controls to framework requirements. They reduce manual evidence work significantly but generally assume you have someone internally who can interpret results and make compliance decisions.

Guided services combine a software platform with analyst support. A dedicated analyst builds the SoA, risk register, and pre-audit checklist with your team, reviews evidence gaps, and prepares the team for auditor interactions. This model is best suited to lean teams without internal GRC capacity.

At Folksoft, our guided-service model is designed for founders and engineering leads who need to move from no formal ISMS to certified status without hiring a full-time compliance person. We pair continuous evidence automation with a compliance analyst who works alongside your team rather than delivering a documentation package and stepping back.

When evaluating any compliance partner, require clear answers to:

• Who builds the SoA and risk register, and is that work included in the stated fee or billed separately?
• Does the engagement include a pre-audit walkthrough that surfaces evidence gaps before the certification body arrives?
• Does the partner have working relationships with accredited certification bodies, or does sourcing an auditor fall entirely on your team?
• What is the total cost of ownership as a single number: platform fees, analyst time, and audit fees together?

The audit fees themselves ($5,000 to $35,000) are always paid directly to the certification body. No platform subscription includes them. Ask any vendor who implies otherwise to clarify in writing.

4. Building the ISMS

An ISMS is not a folder of policies. It is an operating system for information security, and certification auditors evaluate whether it is actually running, not simply whether it is documented.

The core deliverables required before Stage 2 include:

• Scope statement: Defines which systems, services, locations, and teams fall within the ISMS boundary. A well-scoped ISMS covers your production environment and the teams that operate it without artificially excluding assets that auditors will ask about.
• Asset inventory: Documents information assets, their owners, and their classification. For SaaS teams, this includes data stores, cloud infrastructure, code repositories, and the SaaS tools that process customer data.
• Risk assessment and treatment plan: Identifies threats and vulnerabilities, scores likelihood and impact, assigns owners, and documents how each risk is treated: mitigated, accepted, transferred, or avoided.
• Statement of Applicability: Maps every Annex A control to your risk assessment outcomes. Controls you implement are justified by risk findings; controls you exclude are justified with documented reasoning.
• Policy suite: Covers access control, incident response, change management, supplier security, business continuity, and other domains your scope and SoA require.
• Supplier and vendor records: Documents security assessments for third-party processors and critical SaaS dependencies, including the security requirements communicated to each supplier.
• Internal audit evidence: Demonstrates that the management review process and internal audit schedule have been executed, not merely planned.

Platforms that integrate with AWS, GCP, Azure, Okta, Google Workspace, GitHub, and HR systems can collect evidence for many of these deliverables continuously. That means the pre-audit sprint, where teams scramble to reconstruct months of control activity, becomes unnecessary. At Folksoft, our platform integrations pull access review logs, configuration states, and policy acknowledgment records automatically, so the evidence set is current throughout the certification cycle and not just in the weeks before an audit.

5. Running ISO 27001 and SOC 2 Together

If your team is pursuing both ISO 27001 and SOC 2, the most efficient path is to run them as a single evidence program rather than two parallel projects.

The frameworks share substantial control overlap. Three areas where the mapping is especially direct:

• Access management: SOC 2 CC6 (logical access controls) maps directly to ISO 27001 Annex A controls covering identity management, user provisioning, and access review. Evidence collected for one serves the other.
• Incident response: SOC 2 CC7.3 through CC7.5 (incident detection and response) align with ISO 27001 Annex A incident management controls. A single incident response procedure and a single incident log can satisfy both frameworks.
• Change management: SOC 2 CC8 (change management) maps to ISO 27001 controls covering changes in development and operations environments.

The practical approach: run a gap analysis sprint covering both frameworks in parallel. Map your existing controls to both SOC 2 criteria and ISO 27001 Annex A in a single session. Identify gaps once rather than twice.

For teams already operating continuous SOC 2 monitoring, that evidence base can support the operational evidence review in ISO 27001 Stage 2. The Stage 2 auditor still needs to evaluate the ISMS documentation layer, including the scope, SoA, risk assessment, risk treatment plan, and management review records that SOC 2 does not require. Those deliverables must be built regardless of SOC 2 status. The control operation evidence, including access review records, incident logs, vulnerability scan results, and configuration states, does not need to be collected twice when a shared evidence program is already in place.

At Folksoft, we map ISO 27001 Annex A controls to SOC 2 criteria from day one for every dual-framework engagement. The result is one shared evidence program instead of two separate collections running on different schedules.

6. Passing the Stage 2 Audit

Stage 2 auditors test whether your controls are operating as documented. Documentation is necessary but not sufficient on its own.

What auditors commonly verify during Stage 2:

• Access review records: Can you show that access reviews occurred on the schedule your policy defines? Auditors pull samples from across the review period, not just the most recent cycle.
• Incident logs: Is there a complete record of security events, including low-severity incidents? Gaps in the log are a direct flag.
• Vendor records: Were third-party suppliers assessed before onboarding? Do assessment records cover the security requirements you communicated?
• Risk treatment decisions: Are treatment decisions in the risk register documented and traceable to specific control implementations?
• Management review records: Did leadership formally review ISMS performance on the documented schedule?
• Internal audit evidence: Was an internal audit conducted, and were findings tracked to resolution?

Most common Stage 2 failures:

• Incomplete SoA justifications: Controls listed as not applicable without documented reasoning tied to the risk assessment. Auditors expect each exclusion to be justified by specific findings, not a generic statement.
• Missing management review records: The management review is a formal Clause 9 requirement. Many teams document a policy for it but cannot produce evidence that a review actually occurred.
• Undocumented risk treatment decisions: The risk register identifies risks, but the treatment plan does not trace to specific control implementations or record the rationale for risks that were accepted rather than mitigated.

The pattern across all three failure modes is consistent: the policy exists, but the operating evidence does not. A pre-audit walkthrough with your compliance partner, reviewing evidence gaps before the certification body arrives, is the most effective way to surface and resolve these issues while there is still time to act.

FAQ

How long does ISO 27001 certification take for a SaaS startup?

The time from project start to issued certificate varies considerably based on your starting security posture, ISMS scope complexity, internal capacity to work through deliverables, and certification body scheduling availability. A guided-service engagement with continuous evidence collection reduces the manual sprint work, but the overall timeline is also constrained by how quickly the certification body can schedule both audit stages. Build realistic scheduling conversations with your chosen certification body into your project plan early.

Can we reuse SOC 2 evidence for ISO 27001?

Yes, with an important qualifier. SOC 2 evidence covers the control operation layer but not the full ISMS documentation layer ISO 27001 requires. Access review logs, incident records, change management records, and configuration evidence collected for SOC 2 can support Stage 2 operational evidence for ISO 27001 without duplicate collection. However, the scope statement, SoA, risk assessment, risk treatment plan, and management review records are ISO 27001-specific requirements that SOC 2 does not address. Those deliverables must be built regardless of SOC 2 status.

Does a software platform alone get us certified, or do we need a consultant?

A software platform alone does not certify your organization. Certification requires an external audit conducted by an accredited certification body. No platform substitutes for that requirement. What automation platforms do is reduce the manual effort of evidence collection and control monitoring, making the ISMS easier to operate and audit evidence easier to produce on demand. Whether you also need a consultant depends on internal GRC capacity. Teams without a compliance owner typically benefit from a guided service that pairs platform automation with analyst support for the deliverables requiring judgment: the SoA, risk register, and pre-audit preparation.

Conclusion

Three factors determine which partner model is the right fit for your ISO 27001 engagement: the internal GRC capacity your team realistically has, the timeline pressure your pipeline is generating, and whether you are building toward a dual-framework program alongside SOC 2. Lean teams with no compliance owner and a live enterprise deal on the line are not well-served by a template library or a self-service dashboard alone. They need a partner who builds the SoA and risk register with them, flags evidence gaps before the auditor arrives, and maps controls once for both frameworks from the start.

That is the model we built at Folksoft. If ISO 27001 is currently blocking a deal or a procurement conversation, the most useful next step is a scoping call where we map your current security posture to a realistic certification timeline and a complete budget that covers platform, analyst, and audit fees together. Book that conversation at folksoft.tech.

Sources

International Accreditation Forum. "IAF FAQ: Accreditation and Certification." iaf.nu/en/faq/ (accessed 2026).

IAF CertSearch. Accredited certificate verification database. iafcertsearch.org (accessed 2026).

Drata. "ISO 27001 Compliance Platforms." drata.com/learn/iso-27001/compliance-platforms (accessed 2026).

Scytale. "Best ISO 27001 Certification Companies: Costs and Selection Criteria." scytale.ai/resources/best-iso-27001-certification-companies/ (accessed 2026).

ISO. ISO/IEC 27001:2022 - Information security, cybersecurity and privacy protection: Information security management systems requirements. iso.org/standard/27001 (2022).