Getting Started with Security Compliance

Why compliance lands on your roadmap

Most B2B SaaS teams do not start a compliance program because a regulator asks. They start because a buyer does. A mid-market or enterprise prospect runs a security review, a marketplace lists SOC 2 as a listing requirement, or a cyber-insurance renewal asks for attestation status. The trigger is commercial, not statutory, which is why the first decision — which framework, in what order — has more room for judgment than most engineering teams expect.

That judgment gets made badly in two directions. Some teams over-scope: they chase every Trust Services Category or bolt on ISO 27001 certification before a single buyer has asked for it, burning months and budget on categories nobody is gating a deal on. Others under-scope: they treat a security questionnaire as a one-off sales-engineering favor, answer it with screenshots, and end up rebuilding the same evidence from scratch on every subsequent deal. This guide covers the sequence that avoids both failure modes — choosing a framework, defining a boundary, building an evidence habit, and understanding what the first 90 days actually require.

Choose a framework before you choose a vendor

Framework selection should be driven by three inputs: who is asking, where they are, and what data you handle. North American B2B buyers default to SOC 2 language in RFPs and security questionnaires. EU and UK enterprise buyers more often name ISO/IEC 27001 certification specifically. If you process protected health information as a covered entity or business associate, HIPAA obligations apply regardless of what a buyer asks for. If you process personal data of people in the EEA or UK, GDPR applies by virtue of that processing, not by buyer preference — see Article 32 for the security-of-processing baseline.

SOC 2 and ISO 27001 are not mutually exclusive, and for many SaaS companies the honest answer is "both, eventually, in sequence." The framework selector tool walks through buyer geography, industry, and data types to produce a starting recommendation rather than a universal one. For a side-by-side of scope, cost, and typical sequencing, see SOC 2 vs ISO 27001. Read the SOC 2 and ISO 27001 overview pages before committing — both explain what the artifact actually is (an attestation report versus a certification against Annex A controls) and what it is not.

Avoid the common early mistake of selecting a framework because a competitor's trust page lists it. Match the framework to the audience asking for it. A company selling exclusively to US mid-market SaaS buyers gains little from an ISO 27001 certificate that no prospect in the pipeline has requested; a company closing UK enterprise logos will find SOC 2 alone leaves a gap in vendor risk reviews that expect ISO language.

Scope the engagement before you build anything

Once a framework is chosen, define the system boundary before writing a single policy. The boundary is the set of systems, people, and data the audit or certification actually covers — and it should be as tight as the business will tolerate for a first engagement. For most SaaS companies that means: the production application and its supporting cloud infrastructure, the identity provider and access paths into it, the CI/CD pipeline that ships changes to production, and the subset of employees and contractors who can reach any of the above.

What belongs outside the boundary on a first pass: internal tools that never touch customer data, marketing infrastructure, and product lines that have not shipped to a paying customer yet. Expanding categories or scope later, once evidence muscle exists, is normal and expected — SOC 2 reports and ISO surveillance cycles both accommodate scope growth year over year. Boiling the ocean on attempt one is the single most common cause of blown timelines and abandoned programs.

Build the evidence habit early

Every framework, regardless of which one you start with, ultimately asks for the same category of proof: dated artifacts showing that a control operated, not a description of what the control is supposed to do. CC6.1 does not ask whether you have an access policy — it asks for the IdP configuration, the quarterly access review with a named reviewer and a completion date, and the deprovisioning tickets for anyone who left. A.5.15 asks the same question in Annex A language: access limited according to documented business requirements, evidenced by review records tied to your identity provider.

The habit that separates programs that pass smoothly from programs that scramble during fieldwork is simple to describe and hard to sustain without structure: generate the evidence as a byproduct of how the team already works, on a fixed cadence, rather than reconstructing it retroactively when an auditor asks. Quarterly access reviews exported from the IdP, change tickets that already carry approval and test records because engineering requires them for merges, and vendor security assessments logged at onboarding time rather than assembled from memory during fieldwork. CC8.1 — change management — is judged on exactly this pattern: pull request approvals, CI test results, and deployment records sampled end to end from ticket to production.

Type I versus Type II — and why the difference matters early

SOC 2 offers two report types, and choosing wrong wastes a quarter. A Type I report opines on whether controls were suitably designed at a single point in time. A Type II report opines on whether those controls operated effectively across an observation window, typically three to twelve months. Buyers increasingly discount Type I reports because a design opinion says nothing about whether the control ran consistently. See Type I vs Type II for the full distinction.

Many first-time programs skip Type I entirely and go straight to a Type II with a shorter initial observation window — three months is common for a first report — because the marginal cost of a second engagement outweighs the benefit of an interim design-only opinion. ISO 27001 does not have this same split; a certification audit (Stage 1 and Stage 2) tests both documentation and operation in a single cycle, though a formal certificate follows a surveillance schedule afterward.

Your first 90 days

Days 1–30 — scope and gap assessment. Finalize the system boundary, select the framework and categories, and run a gap assessment against the control set. Use the readiness assessment to get a structured starting inventory of what exists versus what is missing, rather than guessing from memory. Identify the auditor or certification body during this window — lead times for a CPA firm slot or ISO certification body booking can run six to ten weeks.

Days 31–60 — remediate and instrument. Close the highest-severity gaps first: MFA enforcement, a single identity provider for production access, and a documented change management process are the three items that block the most audits when missing. Turn manual evidence into automated exports wherever the tooling already exists — IdP access reports, CI/CD logs, and vendor management records should generate themselves from existing workflows rather than requiring a person to compile a spreadsheet monthly.

Days 61–90 — dry run and start the clock. Run an internal dry run against a sample of controls before the auditor's fieldwork begins. This surfaces evidence gaps — a review that happened but was never dated, a policy that was never actually distributed — while there is still time to fix them. Once the dry run is clean, start the formal observation window for a Type II or schedule the Stage 1 audit for ISO 27001. Use the SOC 2 timeline calculator to work backward from a target report date if a specific deal or renewal is driving the deadline.

What to defer

Not everything needs to happen in the first 90 days, and treating every control as equally urgent is a common way to stall a program before it starts. Availability, Confidentiality, and Privacy categories under SOC 2 can wait until a contract or risk profile actually requires them — adding categories later, once Security-only evidence operations are running smoothly, is far cheaper than trying to stand up five categories simultaneously on a first attempt. Formal ISMS documentation beyond what a Statement of Applicability requires, vendor risk-tiering frameworks with more than two or three tiers, and compliance automation platform purchases can all wait until the manual process has run at least one cycle — buying tooling before you know which evidence is actually painful to collect manually often means buying the wrong modules.

Budget realism matters here too. Rough first-year cost ranges — auditor fees, optional tooling, and the internal engineering time that usually dominates the total — are covered in the SOC 2 cost overview. Treat any number quoted before a firm has seen your actual system boundary as a planning estimate, not a quote.

Common mistakes early programs make

The recurring failure pattern across first-time programs is not technical — it is sequencing. Teams start the observation window before access reviews and change management are actually running consistently, which produces exceptions in the very first sample the auditor pulls. Teams pick an auditor based on price alone without confirming the firm has SaaS experience, then spend fieldwork explaining basic multi-tenant architecture instead of walking through evidence. And teams treat the report as a finish line rather than the start of an annual cadence — the second year's audit samples the gap between report periods, and a program that goes dormant after certificate delivery re-discovers every gap it thought it had closed.

Getting the sequence right the first time — framework, boundary, evidence habit, then observation window — is the difference between a compliance program that supports the sales pipeline and one that becomes an annual fire drill.